GPIB ENET 100 and Newport MM4006 stop communicating after a few minutes, but work perfectly fine initially

[Jan_ksu]

Hi guys,

I have a NI GPIB ENET 100 with a static IP, newest firmware and a motion controller MM4006 from Newport. I used both VIs by NI and Newport and initially I can read and write every command I want and it works, but both won't work after 2-3min anymore. I get the following error:

Error 0 occurred at Send in SendCmd.vi

Possible reason(s):

LabVIEW: Error connecting to GPIB driver or device.
=========================
NI-488: Error connecting to driver or device.
=========================
VISA: (Hex 0x0) Operation completed successfully.

Looking into NI MAX, I get an error scanning for instruments after I get the error in labview. I tried a Quantum Composers delay generator that works through VISA, unlike the MM4006, and nothing seems wrong. Everything works without any time limit. Switching back to the MM4006 and the error occurence, I then have to delete the GPIB ENET 100 out of MAX and restart the ENET100. Do I miss something? I used device clear as a last step and when I let it sit for 1 or 2minutes I get the above error.

Thanks Jan

[Hockeyjim07]

Hi Jan_ksu,

Just to clarify you are only having this problem with the MM4006 device correct?

[Jan_ksu]

Yes, I only have that issue with the MM4006.

[JÞB]

That device is not really a GPIB device.  Yes it has some features of GPIB but most of the GPIB common functions are just plain not supported.  

Frankly, I would use the serial interface on that device since it probably limits what other devices on the bus can do because it is not IEEE488 compliant.

You have to love the way its worded in the manual though

"The IEEE-488 interface is implemented on the MM4006 somewhat
differently than on a typical instrument. The standard IEEE-488 command
set and command format are inadequate for a complex motion controller."

(Citation needed):smileywink:  

Sounds so much nicer than "Our engineering staff can't read and implment a IEEE standard."

Spoiler

Yeah GPIB could handle the command set needed.  I've seen much larger sets implimented 

[Jan_ksu]

I remember reading some line like that, but I just ignored it. Unfortunately the serial port does not work on the device. I used to communicate over a Prologix GPIB-USB device and I inherited some code, but right now the time for the device to communicate over the GPIB-USB device takes roughly 2sec between measurement points. My boss bought this GPIB-ENET in hopes it would accelerate this communication. I do have a ESP-300 on a different setup with the same equipment and it only takes 0.14sec.

I can make it work with the GPIB-USB device and it works initially with the GPIB-ENET100, there has to be something I could do. It looks like that in situations where I let it idle for too long, it stops working. A terrible work around would be to send a constant stream of commands (even though I don't make use of any of those commands) to the device. I'm not sure if that works..

[JÞB]

GPIB-USB device takes roughly 2sec between measurement points.

---

 That brought back some painful memories.....

Try setting the unaddressing to True  VISA GPIB INSTR property GPIB Settings:Unaddressing=TRUE.  

Also play with "Message Based Settings:Termination Character Enable"

One or both at non defaut value may help. since the hanshaking is not standard for modern devices.

[Jan_ksu]

Here is an old thread out of the forum: http://208.74.204.114/t5/LabVIEW/GPIB-write-is-working-but-GIPB-read-doesn-t-work/td-p/164284

This user has some issues, but states also that it formerly worked with the very same setup that I have. Do you think any other GPIB 488.2 version/visa version might do the trick?

[Jan_ksu]

Sorry for the double post, but I didnt see any possibility to edit my previous post:

I'd like to make this GPIB ENET100 and MM4006 combo work. I share the unit with another coworker and it would make it more convenient to have a device that is accessible over the network.

[JÞB]

Looking back at that driver (~~~~don't look!)  No errors or warnings are reported to the caller and it uses the very old 488 API (predates VISA by a few years.)

It fails to implement the read mode 2 that the manual for the device states must be set so all reads will likely timeout  Hey the default is 2 seconds explaining your loop time.

Follow the edvice previous and set the VISA term char and enable to \n and true (neither is the default) and you should stop sending the device into neverland.

[Jan_ksu]

Sorry for my late response, but I will try that later and will keep you posted.

Thanks