Twilight-Logic
REN pin always active?
Hi,
I thought I had a uno with blown pin 3 (REN), as it is always ~0v (active), but with another sketch (blink sketch, modified to use that pin) it cycles.
I tried another uno and a duemilanove (which also uses the atmega328p) - on both, the pin works with a test sketch but doesn't seem to work with the AR488 sketch uploaded.
None of the following change the state of that pin:
-
++xdiag 1 32(assert REN) -
++xdiag 1 255(assert all) -
++xdiag 1 0(assert none)
The latter two do change the state of other pins.
++mode reports 1, so it should be in controller mode.
Is it to be expected that the pin is not driven high? The documentation of xdiag makes it sound like it should change state, same as other pins...
I'm using rev ae02a638c (Mar 18), which looks to still be HEAD.
At this time I am not sure but I will check it out. AFAIK, it should change state. It will stay low when in controller mode, but it should change for 10 sec when running xdiag.
Ah, sounds like it wouldn't be negatively affecting me even if it was malfunctioning.
I fiddled some more and got it talking to one of the 3 devices I have that support gpib, a HP 3582A.
I'd left pin 24 (logic gnd) disconnected, thinking it'd be connected to the other grounds; apparently that is untrue.
The device I most want to use with gpib (Tek 7912AD) seems to require a secondary address; I see in the documentation that this is not implemented. Do you have any idea how much work is required to get that going?
I haven't had a chance to have a look at the REN issue yet. I need to hook an UNO to an LA and see what each line is doing. So far only got as far as getting the LA out....
With regards to secondary addressing, I will need to study the Interfacing manual a bit more in order to be able to answer. Generally, the primary address is used do identify the instrument on the GPIB bus, whereas the secondary address is used to send commands. The command set is specific to the instrument. For example, last year I completed a collaboration project for the Tektronix 4924, which is a tape drive designed for the Tektronix 4050 Series computer. The tape drive uses secondary address codes as commands to control the tape and read and write files. In the case of that project it was the AR488 interface board that emulated the tape drive and received the secondary address over GPIB from the instrument and then did something with it, for example saving a file to an SD card.
From a quick skim read of the Interfacing guide I see that the secondary address on the 7912AD is used in a similar way but there are differences. For example, the instrument uses the secondary address plus the next two addresses in sequence to determine whether a command is being sent to the mainframe, the channel A plugin or the channel B plugin. It looks like it requires a sequence consisting of PRI, SEC, "some command string", to be sent, where PRI is the primary address of the instrument on the bus, SEC is the secondary address, i.e. the mainframe or +1 for the channel A plugin or +2 for the channel B plugin, and the string contains the command for the addressed component to execute. However, in this case, the roles are reversed. The instrument receives the secondary address and command sequence and does something with it. The AR488 would need to commanded via serial and forward the instrument command string to the instrument.
The Interfacing manual contains examples using Tek 4050 BASIC. In this case, BASIC composes and sends the required sequence of bytes to the instrument and interprets the response. However, if you don't happen to have a Tek 4050 series computer to hand (do you?), then a method of emulating Tek BASIC will be needed. That could be done easily enough using, for example Python, or some other scripting language that can access the serial port. However, what would still be needed is for the AR488 to 'know' when it is being provided with a secondary address. Crucially, this has to be sent as a byte following the primary address byte while ATN is still asserted rather than subsequently when the instrument command string would be sent. What might be needed is to provide a means for setting that secondary address, perhaps like perhaps +addr 3,1. If the second parameter is provided, the controller would interpret is as a secondary address to be sent after the primary address. Following that, the instrument command sequence is sent. If necessary the response is retrieved with a ++read command. The calling program then interprets what it has received based on what the programmer was expecting. If no secondary address is provided, the controller just assumes it is sending to the primary address. The only difference here is that the primary address only needs to be set once. The primary,secondary address combination will need to be sent every time an instrument command is sent, e.g:
++addr 10,0
DIG DAT;READ PTR, VER
This would be equivalent to the Tek basic command:
PRINT @10,0: "DIG DAT;READ PTR,VER"
In the above statement, 10 is the primary address and 0 is the secondary address. Conversely, the equivalent of this sequence:
PRINT @10,0:"VS1?"
INPUT @10,0:VS1$
would be:
++addr 10,0
VS1?
++read
The result of ++read would be read from serial into a variable.
Not sure whether it is quite as simple as that, but it sounds like it might be feasible. Since you have the instrument, would you be willing to test if I set something like that up?
I'd be happy to test it for you, thanks!
Speaking of REN, I'd meant to see if I could find an arduino emulator and see if it showed activity on that pin.
I was also wondering if it was possibly supposed to use the pull-up resistor, meaning the pull-up enable circuitry was faulty on the arduinos I'd tried.
One caveat on testing: when I hook the 7912 to a scope in x-y mode it doesn't behave as I'd expect. I hope that GPIB will allow me to narrow down the issue(s), though it's also possible said issue(s) will interfere with proper GPIB function and thus with testing the updated AR488 code.
Tekwiki has incomplete documentation on these digitizers, so any in-depth troubleshooting will get interesting.
Mark, I tested the ++xdiag function this morning but couldn't replicate the problem in the same way. I had the AR488 connected to the logic analyser and no other device connected to the GPIB bus.
The first thing I noticed on my UNO was that in controller mode, both REN and SRQ are low, In device mode all pins are high as expected.
Now, in controller mode, REN is supposed to be LOW. This is so that in controller mode, devices can be remote controlled. As soon as one drops unasserts REN, all devices on the bus return to local mode. To be fair, I am not certain whether it should be idle on startup and asserted when a remote command is issued and then perhaps cleared on ++loc. However, it shouldn't cause any problem with remote control.
On the other hand, SRQ should be idle (HIGH).
However, ++xdiag 1 0 does pull all the pins up HIGH and ++xdiag 1 255 does pull them all low. So I am baffled as to why SRQ goes LOW in controller mode. It is evidently capable of being pulled up HIGH. Your thought about the pull-up is an interesting one, but you did say the problem occurred on more than one board? You did also say it worked OK with another sketch?A similar thought occurred to me as well regarding this SRQ problem, but since I can see on the LA that ++xdiag 1 255 can pull them all up, that is evidently not the issue in my case, so something for me to investigate further.
On the secondary addressing front, I have made some progress, but then realised that my approach was going to be a little more complicated than first envisioned. I think I need to change my approach somewhat and am still considering the options.
I have attached a test version for you to try secondary addressing. To send a command the instrument use the new ++sendsec command as follows:
++sendsec 1,0,COMMAND TO SEND
where the first parameter is the primary address, the second the secondary address, and the third is the command sequence. No idea whether this is going to work, but I am hoping you get at least some response.
There is still much more to do as it looks like there is a needs to send individual bytes which will likely require a separate routine.
Let me know what happens.
Your thought about the pull-up is an interesting one, but you did say the problem occurred on more than one board? You did also say it worked OK with another sketch?
Yes, 3 different boards. I believe all 3 came from an estate I helped clean up, in which case they could all be damaged similarly (without me knowing), though it seems unlikely.
With a sketch I was only testing high/low, not low vs pullup. Rise and fall time appeared the same on different pins; I assume a damaged transistor would show up as slower rise time, and of course if sufficiently damaged no rise at all :)
Part of your comment references SRQ rather than REN - did you mean REN throughout?
I'll give your attached sketch a try and let you know.
With any sendsec command (e.g. ++sendsec 4,5,READ VER), the AR488 responds with Sent!.
I've not seen any response from the instrument for any sendsec command. That said, I don't have a display attached and I think some front panel indicators need replaced.
++llo turns on the unit's lockout indicator, regardless of the address set by ++addr. (contrary to the ar488 docs - ?!)
++loc does nothing
++ loc all turns off the lockout indicator
Did you try following up READ VER with a ++read command? The 'Sent!' is there to indicate that the function completed and didn't jump out at any of the return statements associated with an error.
Interesting note regarding ++llo. Need to look into that.
I'd set ++auto 1 prior to the sendsec command.
I also tried with ++auto 0 and issuing ++read after; there was no difference.
prologix examples I see online (eevblog, etc) require that 96 be added to the secondary address. Are you doing that internally or should I add it myself? If the latter, I believe there's a bounds check getting in the way: ++sendsec 4,101, ... results in an Unrecognized command response that I don't get for SAD values < 32.
I'm a little confused why you added another command, sendsec, and changed addr to accept an optional SAD.
Is ++addr PAD SAD usable, or is SAD just discarded? As with sendsec, SAD >= 32 results in an error.
Mark, thank you for your further notes.
I started with the idea of using the ++addr command to set the secondary address i.e ++addr PAD, SAD, and got as far as coding the process to accept the address, but realised that the matter was a little more complex that I realised at first. Therefore I changed tack and added the ++sendsec command which is the one to use. I hadn't yet removed the code in ++addr.
With regards to the PAD address, yes there is a bounds check as GPIB addresses are normally between 1 and 31, with 0 being the controller. However, it also depends on whether you want the receiving device to talk or listen. So if you want the device to listen you add 32 (hex 0x20) to the address. If you want it to talk you add 64 (hex 0x40). The controller already takes care of that for PADs depending on the command used. For the secondary address one adds 96 (hex 0x60) which I hadn't taken into account. I am wondering whether some Tek BASIC commands do that automatically depending on whether expect to send or receive something..
The attached has the restriction removed which should allow you to experiment further. I will look at it in more detail later and will probably remove the additional code from ++addr.
Interesting, I didn't realize talk/listen required different addresses. Explains the table I saw in an HP manual which had both. Though it also showed the default address as +K, IIRC (presumably ASCII for the talk and listen addresses)... :dizzy_face:
Regarding ++addr, I failed to mention my main points: that it'd be good to retain compatibility with prologix, and otherwise a lot of other commands need re-implemented.
For example, ++clr uses the address set via ++addr. How would I send it using ++sendsec? Or do commands like that only operate with primary addresses?
With the updated sketch, I'm still not having any luck. I can send to 101 without error but still get no response.
Even though +llo turns on the lockout indicator, other front panel buttons function. So I'm thinking this 7912 is suspect enough that additional fiddling is pointless without a logic analyzer. Either I cobble one together, or transport the digitizer to the local makerspace. Effort either way, yaaaaay.
Thanks for the help, and I'll update you when I know more.
The details of the original GPIB design are explained here:
https://www.hp9845.net/9845/tutorials/hpib/
I do intend to retain compatibility with the Prologix interface so the ++addr command will be retained. I was only going to remove the bits I added to support ++addr P,S. I will just leave support for ++addr P as previously. You are correct that commands like ++clr, ++loc and ++llo operate on primary addresses.
Can I ask for a link to the HP manual you mention please? If its in a BASIC program statement then it may just be a variable, but I am also curious about that +K reference.
I wouldn't necessarily consider the 7912 suspect. We are rather working a bit in the dark here. I don't have a 7912 instrument here to test with and having a logic analyser to view what is happening on the GPIB bus would be useful for sure. If you are familiar with Sigrok, then Artag's GPIB sniffer board here makes it easy to connect up to the GPIB bus:
https://oshpark.com/profiles/artag
It is relatively cheap and easy to build as well. Of course, there are a large number of options.
If ++llo turns on the lockout indicator that would at least seem to indicate that at least primary addressing is working as the instrument is receiving the command. Of course ++loc should turn it back off again so I tested that on my Agilent 34401 meter. Running ++llo lit up the 'Rmt' indicator and locked for the front panel and both '++loc' and '++loc all' turned it off again and released the front panel again. It does appear to be working as it is supposed to do. I would expect the 7912 to respond in the same way, however I am not familiar with it and need to find a bit more time to study the manuals, which will be difficult to find this week. Things should be a bit quieter next week.
Looking at some of the examples in the interfacing guide, it would seem that each time you 'PRINT' a command, there is a corresponding INPUT or READ command with secondary addressing to obtain the response. It may be that the ++read command needs to be updated to take into account the secondary address as well. Of course it would be useful to confirm proper operation of primary addressing first.
The manual mentioning +K is the operating manual for the 3582A. It can be seen at archive.org. The default address is mentioned in paragraph 2-33 (pdf pg 27) and the table is on the next page.
Thanks. That's a bit of a weird way that HP have referred to it in that manual. So if you look at the table over the page, you can see that listen + and talk K refer to the same row of the table corresponding to an address setting of 01011 which is binary for 11 decimal, or 0B hex. Now if you look at an ASCII table for the characters, you will see that the character + is ASCII code 53 or hex 2B, and K is 113 or 4B in hex. So the switch is set as indicated to configure the primary address value to 11 or hex 0B and then hex 20 or hex 40 is added when sending commands depending on whether the instrument is being addressed to talk or to listen. So in the example BASIC statements you would use decimal address 53 for a listening (INPUT, RBYTE) command or 113 for a talk (PRINT, WBYTE) command.
On the AR488 (or Prologix) you would just set +addr 11 and the interface handles the rest.
However, this is primary addressing not secondary as per the 7912AD.
I have been working on couple of other things , one of which has involved secondary addressing. Some changes have had to be made to the GPIB back-end code. In addition I removed the previous experimental functions and added two new, written from scratch functions called ++secread and ++secsend. These have been reported to work so hopefully should now work with your 7912AD. This is the latest development version.
As before the send function is called with:
++secsend pri,sec,data
The read function just needs the addresses:
++secread pri,sec
It is also possible to do the same thing with single commands:
++unt
++unl
++addr pri,sec
++read
or instead of ++read, send something to the instrument.
I am currently working in added a 'Find listeners' function. This is called with:
Single or multiple addresses (separated with comma, space or tab):
++fndl addr, addr, addr etc
Range of addresses:
++fndl begin-end
Complete range from 0 to 30:
++fndl all
It should return all listeners on the bus, including extended addresses. The function is still being worked on and the extended address (pri,sec combination) results may not be accurate.
The ++xdiag function has also been enhanced to show the diagnostic or current pin state in the serial terminal.
To show the current pin state:
++xdiag pins
The other options work the same way.
I am still considering how to handle REN.
Note that ++secsend has been renamed to ++send and ++secread has been merged into the existing ++read command.
Awesome! I had poked at the code a bit off and on, without a breakthrough. I was just coming back to this and noticed you'd added functionality. Hopefully it gets the 7912 working - I'll keep you posted.
BTW, would you be interested in a Makefile, for use with arduinoMakefile? You still need the arduino ide installed, but it lets you skip running the ide. You can compile/upload from the command line with something like MONITOR_PORT=/dev/ttyACM3 make upload. I've only tested on linux, but assume it also works on windows and osx.
If you are interested let me know and I can create a PR.
I'm able to address it now, so it's happy with how you are doing secondary addressing.
Still having some issues, though at least some are due to me not understanding how it responds in particular cases - for example, if you try to read and it has nothing to say, it responds with 0xff.
When you use it, do you insert delays in whatever program is controlling it? For stability, I found I needed to insert delays between writes.
I'm not sure you can do much about this, given the constraints of the atmega, but it may be worth documenting (unless it is already and I missed it).
BTW, would you be interested in a Makefile, for use with
arduinoMakefile? You still need the arduino ide installed, but it lets you skip running the ide. You can compile/upload from the command line with something likeMONITOR_PORT=/dev/ttyACM3 make upload. I've only tested on linux, but assume it also works on windows and osx.If you are interested let me know and I can create a PR.
That sounds interesting. I would be happy to have look and experiment with that. I am also thinking of creating a PlatfromIO project config for it at some point, but keeping the original Arduino IDE format as well.
I'm able to address it now, so it's happy with how you are doing secondary addressing.
That's good to hear.
Still having some issues, though at least some are due to me not understanding how it responds in particular cases - for example, if you try to read and it has nothing to say, it responds with
0xff.
Hmm, might need to have a look at that. The interface shouldn't be sending anything if the instrument has nothing to send.
When you use it, do you insert delays in whatever program is controlling it? For stability, I found I needed to insert delays between writes.
I'm not sure you can do much about this, given the constraints of the atmega, but it may be worth documenting (unless it is already and I missed it).
That's a fair point. I recently added a ++flags command which allows a script to wait and check that the 'flag' (defined sequence of characters) has been received before sending the next command. Not sure whether that would help in this case but might be worth a try, but otherwise, with chips like the CH340 in the absence of handshaking, fudging it with delays is the only other option.
Ok, I'll put together a PR. Fortunately this won't be impacted by the re-formatting issue I mention below.
The interface shouldn't be sending anything if the instrument has nothing to send.
This isn't the AR488's doing. The 7912AD operator's manual just got scanned and notes this behavior.
From page 3-16 of the ops manual, available on tekwiki's 7912AD page:
... If the 7912AD has no message to send when it is talked, it responds with a single data byte, hex value FF -- all data lines asserted, along with EOI.
One other note: Have you considered using a code pretty-printer? When I was poking at the code, vscode was absolutely determined to reformat all the C/C++ no matter what I did to turn off its auto-formatting. If I'd wanted to submit a patch, either it would have been a garbled mess or I would have had to re-create the patch in a different editor. VSCode re-word-wrapped everything, "fixed" spacing, replaced all tabs, etc etc.
Using a pretty-printer wouldn't fix everything unless its settings agreed exactly with vscode, but chances are it'd clean up a number of the things vscode felt it must change.
(This reminds me, I should try to reproduce and file a bug against vscode)
The Makefile PR is up now - #63
We've gone far beyond the original scope of this issue, so I think I'll close this.