REN pin always active?

[mpictor]

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 ae02a63 (Mar 18), which looks to still be HEAD.

[mpictor]

any thoughts @Twilight-Logic ?

[Twilight-Logic]

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.

[mpictor]

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?

[Twilight-Logic]

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?

[mpictor]

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.

[mpictor]

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.

[Twilight-Logic]

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.

[Twilight-Logic]

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.

AR488_test_SA01.zip

[mpictor]

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.

[mpictor]

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

[Twilight-Logic]

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.

[mpictor]

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.

[Twilight-Logic]

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.

AR488_test_SA02.zip

[mpictor]

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)... 😵

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.

[Twilight-Logic]

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.