Has anybody successfully interfaced RA488 + HP 7475A HP-IB Plotter

[redruM0381]

Built a RA488 today w/ Mega 2560. After configuring controller mode, I can send individual commands, such as SP1; SP2; etc. to my plotter, and it responds accordingly. But if I try to send more, such as an HPGL file, it stalls, and errors out on the plotter side. Plotter is in listen mode, but I have tried an address also.

I suspect it's a buffer overflow, but I can't for the life of me figure out the combination of configuration that it likes.

Any suggestions?

[Twilight-Logic]

That does sound like it. Which board are you using for your build please?

[redruM0381]

The board is a Mega 2560, probably a clone. Do you maybe suspect a fake USB/serial bridge chip? I noticed I am unable to use CTS, which others recommend with the Prologix unit...

I could try a genuine FTDI bridge, and tie it into one of the other serial ports.

[Twilight-Logic]

Many clone boards use the Chinese CH340 UART chip, which as you noticed, does not implement RTS/CTS handshaking signals. These signals are exposed on a couple of its pins but generally are left unconnected. This means that serial throughput is not controlled, leading to serial buffer overruns. As a result, data is lost during transmission which is obviously undesirable. The FTDI FT232RL does implement serial handshaking on the chip so this should hopefully work correctly. Let me know how you get on with the FTDI bridge.

[redruM0381]

Tried today w/ a SH-U09F bridge (genuine FTDI chip) on the TX0/RX0 pins of my Mega. Results are the same. If CTS is enabled, TX turns red in my terminal, and I am unable to transmit anything. With CTS off, I can communicate, but still run into major buffer issues.

[Twilight-Logic]

Thanks for reporting back. I thought using the FTDI would solve it, but on reflection, although there would be RTS/CTS flow control between the PC and UART, I guess those signals would still need to flow between the FTDI and the Mega2560 chip top control the flow from its serial Rx/Tx pins. I think that could be built into the Mega2560 since it has plenty of pins but will require some time to experiment with.

[tpolecat]

I was messing with this today and found that there are three main issues, none of which are AR488's fault. I fixed them by shameless hacking but one could certainly do it elegantly.

1. Plotter commands can take an arbitrary amount of time to complete, which can result in an NDAC HI timout if cfg.rtmo isn't set high enough. When this happens commands continue to be sent, but the plotter is in a bad state and will have missed some steps. Setting this with ++read_tmo_ms didn't seem to work so I just hardcoded it to 10000 (10 seconds).
2. The UART buffer can fill up (as mentioned above) which will cause commands to be missed. A solution to this is to do some simple handshaking, which I did by just turning on debug output and waiting for (sendToInstrument) > done before sending the next command. I'm sending commands one at a time.
3. When first connecting via serial it can take a few seconds to initialize, so I handled this by waiting for > Initialised GPIB control mode before sending my first command.

Anyway, with these things in mind you can send commands as fast as the plotter can handle them. Hope this helps.

[Twilight-Logic]

Oh, that is interesting. All that ++read_tmo_ms does is set the value of variable rtmo as defined in the struct at the beginning of AR488_GPIBbus.h (line 148). The expression cfg.rtmo is a reference to this rtmo variable. Could I ask where in the program you hardcoded it? I am presuming that it was in the GPIBbus::readByte function? Of course, after setting this value, for it to survive a reboot, you would need to run ++savecfg to save it into EEPROM as well.

Your method for rudimentary handshaking is also noteworthy. Perhaps this could be added as a feature! It should be simple enough to add a command to turn on sending of a unique character sequence (e.g. something like "Send^OK") to indicate that the send is done.

Connecting to serial causes a UNO or Mega 2560 board to reset which takes about 2 seconds. It would also take a little time for the Arduino to GPIB in either control or device mode, so again, something could be added to indicate that the interface has reached a ready state. Since evidently you needed both, perhaps turning on such flags could be grouped into one command. There is actually an option that can be turned on in AR488_Config.h by un-commenting the following:

#define SAY_HELLO

However, the prompt also includes additional information that is not required for this purpose.

Thank you for taking the time to provide this feedback. It has been very helpful.

[tpolecat]

Hi, thanks for the quick response! This is great project.

Connecting to serial causes a UNO or Mega 2560 board to reset

Aha, this must be why the ++read_tmo_ms wasn't sticking. I was switching between the IDE serial monitor and a Scala program I was using to compute the stream of plotter commands. I will track this down … I'm confident that it's working correctly on your end.

I hardcoded the 10 seconds at the third line of GPIBbus::writeByte … the plotter doesn't acknowledge the last byte of the command until it's finished executing, so it stays in RECEIVER_ACCEPTING too long and times out.

I will see if I can add commands to enable saying hello and indicating send complete. If it works I'll send you a PR.

[Twilight-Logic]

Hi, thanks for the quick response! This is great project.

Glad you like the project. Thank you for your support.

Connecting to serial causes a UNO or Mega 2560 board to reset

Aha, this must be why the ++read_tmo_ms wasn't sticking. I was switching between the IDE serial monitor and a Scala program I was using to compute the stream of plotter commands. I will track this down … I'm confident that it's working correctly on your end.

Yes, that might explain it. The setting should hold within the current session though.

I hardcoded the 10 seconds at the third line of GPIBbus::writeByte … the plotter doesn't acknowledge the last byte of the command until it's finished executing, so it stays in RECEIVER_ACCEPTING too long and times out.

Well that might certainly explain the timeout. I figured that you probably modified it on that line, either there or in the while loop condition. Was just curious which. Looking at that, timeval probably does not need to be declared. The loop condition could just refer to cfg.rtmo.

I will see if I can add commands to enable saying hello and indicating send complete. If it works I'll send you a PR.

Funnily enough I have just been playing with this idea as well and added a ++flags command. For now, it adds 3 flags - AR488~RDY, Read^OK and Send^OK which can be individually turned on or off as required.

[tpolecat]

Funnily enough I have just been playing with this idea as well and added a ++flags command. For now, it adds 3 flags - AR488~RDY, Read^OK and Sent^OK which can be individually turned on or off as required.

Excellent, happy to try that out for you when it's ready.

[Twilight-Logic]

Just seen that our posts crossed, so moved the attachment here.

Bits 1, 2 and 3 correspond to the flags mentioned in the previous post. To turn on AR488~RDY and Send^OK you would send ++flags 3. You would also need to do a ++savecfg and reset to observe AR488~RDY. I would be interested to know whether this works.

If you have alternative ideas that you want to try, then by all means experiment and send a PR when ready. In the meantime I have attached my effort based on your observations.

AR488-test-flags.zip

[tpolecat]

Hi, I just had a chance to try out ++flags and it works perfectly. I switched my code to expect the new messages and everything works great. Thanks so much, super helpful.

[Twilight-Logic]

That is good to hear. The feature will be included in the next release which will hopefully not be too much longer in coming.

[Twilight-Logic]

Please note that there was an error in the above which has been corrected in the release. The value to turn on the Send^OK flag is 0x04 not 0x07. To turn on AR488~RDY plus Send^OK requires ++flags 5. A value of 0x03 turn on AR488~RDY plus Read^OK. A value of 0x07 should turn on all flags.