Intermitent VISA Write error - Pulling hair out

[Dennis_Knutson · Accepted solution]

Sorry, I looked at the VI and did not notice the image.

I don't think I've ever had a timeout on a write. Getting any sort of error on a write is next to impossible. Since enabling the termination character only affects a read, I can't see how this will make a difference. Besides doing the configure only once, you could see if there's an updated driver for the serial card.

I just thought of a reason to get a write timeout. I'm using a phone right now so I can't look at the VI and I don't remember but are you using handshaking? A problem there could cause a timeout.

[dacad]

Will check for a newer driver. Hadn't thought of that.

No Handshaking,   9600 Baud, 8 Data bits, No Parity, 1 Stop Bit, No Flow Control.

Have tried swapping ports one more time to see if that affects it.  I have had some devices that are not as stable on higher port numbers, by that I mean anything above Com 1 or Com 2.

--------

Just looked, there is indeed a newer driver.  WIll install it shortly and hope and hope and hope that it will resolve the issue.

Thanks for that thought......

[Dennis_Knutson]

Another thought is to turn on NI-Trace/Spy. As I said, it's next to impossible to get a write timeout. Typically, you can do writes all day long even without an instrument connected.

[josborne]

Try increasing the VISA timeout:

http://digital.ni.com/public.nsf/websearch/E4F90AD24DEC9CC786256F4300605C02?OpenDocument

[dacad]

Glad I have figured out how to do the next to impossible and create these write timeouts.  Not the superpower I was hoping for though.

Installed the updated driver and the system just started back up.  Crossing my fingers.

Am not familiar with using NI-Trace/Spy so will have to look at that and figure out how to use it and then figure out what it is going to tell me.

Timeout is already at 5 full seconds.  Was at 10 but I reduced it several debugging steps ago thinking that it may have been intruding on itself (one of those outside the box thoughts)

I have watched it error out.  Takes a small fraction of a second to working correctly to error on screen so I don't believe increasing it back is going to impact it.

I hear what you are saying about it being hard to generate a write timeout which makes all the more frustraating.  Am pinning all my hopes on the driver update at this point.  If that doesn't work, am going to order a different IO card.

No thoughts on adding the Clear Buffer before the Write ?

[JÞB]

Looking at the datasheet (for whatever its really worth) the 128byte buffer seems like a possible source for a write tmo error.

Try setting the VISA buffer to 128

try writing in chunks no larger that 128 bytes (encluding term chars which, you will need to do manually since you don't want them every 128th char of tx)

Try better hardware

let us know what you find

[AKA_TG]

This sounds like a very  tough problem dacad.

Unfortunately we are not privy to the stepper motor command set or user's guide.

It is difficult to imagine a stable working serial connection to a device when the data travels only one way and there is no acknoledgement in return.

Perhaps the status of the serial port can be queried or setup before doing the write. WIn7 may also prefer asynchronous operation over synchronous.

Getting a write error indicate VISA has indeed timed out on the data transfer to the device but how is a mystery. The operating system does the actual transmission to the device.  

 Given no other info I would start at the wiring and handshaking ALso if it is possible I would initialize the device or send it another command before the one to move the stepper. OR Try changing the com ports so that stepper is on com1.

OR see if the problem still happens when running the AE  by itself through move commands in a loop without any other serial ports or parallel loops

being used. (you could make the move very small or have each second move return back to the original position. It might give you some insights.

HIH

[dacad]

A little rusty on bytes and bits. Each alpha/numeric character (including spaces, termination characters, etc) = 1 byte,  correct ?

That being the case my longest string is   CC1.3\rMR13\rAC100\rDE314\rVE4\rDI-1\rSH4F\rDI21609\rFL\rCI0\r  for 62 bytes and only occurs during initialization and at the end of the sequence.  The strings being sent when the error occurs are only 35 bytes long. (ex  AC100\rDE100\rVE1\rDI500\rFL\r)

Have not had error since updating driver at noon but not holding my breath. When (if) next error occurs, I will add buffer sizing to the init case.

Stepper drive is a model 3540i from Applied Motion.  The command syntax is incredibly simple (though not necessarily intuitive).  Values sent are retained until overwritten or the device is powered off/on.     AC100 = Setting stepper acceleration to 100, DE = deceleration, VE = velocity,  DI = direction/distance (a minus sign is other direction), FL = perform the move based on the other parameters.    The FL command can be sent by itself as the other values are retained.

The wiring is a just a std 9-pin serial to an RJ45 jack the goes into the driver board.

If I can get to the system when production is not running, I will set up an infinite loop to try and force the issue. Easy enough to make it move backand forth.

Will see what happens the rest of today and report back on Monday.

Thanks for all the input......

[JÞB]

I too, hope the driver update addresses the issue.  Yes, Bytes=Chars.  Do check the power on pin#9 jumpers for the PCI card.

Remember, the "RS"  in RS-232 means "Recommended Standard"  a well writen user's guide in a "must read" for serial interfaces.

[dacad]

Well, after a day and a half, no errors have popped up though there was one glitch were something just stopped communicating.  I'll chalk that up to an anomaly.  My feeling is that the updated driver fixed it.

Now.....  I have an identical system running a different application that runs the same stepper drive and reads a digital indicator via serial.  I did have to play with port selection initially on that one but it has otherwise run completely stable since.  The question is of course,  update the serial driver or not.  My gut says, it's working, don't screw with it.  I should look though, it oculd always be that particular IO card shipped with the updated driver.

Four more systems to go and I will use the newer driver for those.

Thanks for the all the feedback on this from everyone and ecspecially to Dennis for making the driver suggestion.  Kudos left.