Intermitent VISA Write error - Pulling hair out

[dacad]

Running an app that uses a couple serial devices.  One is a stepper drive that is controlled by simply sending command strings to the drive controller via serial connection.

Have had to update to Win 7 (from XP) and as well upgraded to LV 2013.    Now all of the sudden I get errors from the vi that writes to the serial port. Sometimes it goes for a couple hours before popping up, sometimes 15 minutes.  There is not even much consistency as to which iteration of the vi pops the error.  I have added delays here and there, put a delay in the write vi (attached), added a clear buffer before the write, etc, etc.  This bug will not go away.  this is the error that  pops up..

I have attached the vi.  It is about as simple as they come which is why I am pulling what little hair I have left out.  Two changes in this version from the original that ran forver on the XP system, the 150 ms delay between Write and Close (since increased to 400) and I have also changed the timeout on the Configure from 10000 ms to 5000 ms (10 sec to 5 sec).

Once this happens then all serial connection with the computer is hosed and I have to reboot the system to get going again.  The computer, a relatively new dell, has one built ini serial and I am using a StarTech expansion card for two additional ports. (2 Port PCIe RS232 w/ 16550 UART)

ANY help is much appreciated on this as having to go reset the system 10-15 times a day is killing me.

[ben64]

There is not much information provided in the VI you attached so I will try to guess.

I suppose this VI is in a loop and is use to send repetitve commands to the unit. If so the Configure serial port and VISA Close functions should be respectively before and after the loop. Only the Write command should be in the loop. It doesn't make sense to open and close the serial port every time you're sending a command.

Ben64

[JÞB]

Give Ben(64) an honorary 8-Ball!

Ben's(Raynard) famous Action Engine Nugget is always a good read. http://forums.ni.com/t5/LabVIEW/Community-Nugget-4-08-2007-Action-Engines/m-p/503801

An AE with an enum <Null, Init, Write, Read, and Close (Optionally, a nirvana type "Query" calling "Write", delay, "Read" )>  would go a long way!

[dacad]

It only gets called when a stepper move is required.  It is not in a loop.  The main app is for an assy operation.  The vi is called to perform a stepper move. Several other steps occur and if required, it is called again.  This can go on for 5 to 15 iterations and is in a state machine.  When the assy process is done, it makes one more call to return the stepper to home.  That is the longest string that is ever sent as shown below.

CC1.3\rMR13\rAC100\rDE314\rVE4\rDI-1\rSH4F\rDI21609\rFL\rCI0\r

Not sure what other information I can provide.  I have since the first post, added a 100ms selay between the Clear Buffer and Write command and also turned the Enable Termination Character to True (it still functions but was just done within the past 10 minutes so not sure if it is going to help in the long term)

[dacad]

I can implement and AE structure and see if that changes anything.  The only thing I do on this device is write string commands.  No reads or anything else so the AE would only have Init, Write and Close.  Seems a bit overkill for this but I am willing to try anything to remove the error.  Will be tomorrow before I can try it.  Will do it first thing and advise on results.

Any other thoughts in the meantime are welcome.

[Dennis_Knutson]

The Configure Serial Port should only be called once and you are saying it is called multiple times.

You also have not provided the error number or message that you get. Essential information that is missing.

[ben64]

Dennis, the error number is in the picture of the first post (Timeout expired before operation completed).

Ben64

[JÞB]

Let us make no mistake. 

You close the VISA resource in the "Write to Stepper.vi."   That means each time you call it the resource is re-opened, re-configured and closed again. 

This is BAD.  Open and configure the VISA session when your app starts - Close it when your app exits.  Or, continue suffering the consequences when VISA calls to open and configure the port race with VISA calls to close it.  Remember you are merely requesting "Open" and "Close" operations-  the OS will service those requests in whatever order is convenient for it.  Not the order convenient for you

[dacad]

I hear what you guys are saying.  Using the current method has never caused a problem until I started migrating to Win 7.  This method was learned by reproducing code that was put in place by an outside contractor when I was still green and didn't know the wise ways of LV.

So far, since I made the last changes late yesterday, the system has stayed stable.  Any thoughts what impact the termination character can have? (true or false)

I will proceed to make a revised version that isolates the open and close. (What is being called and AE.  I have used the technique on other things but never coined a term for it)

Also, any thoughts on the clear buffer function being used before the write?

Thanks for all the input

[dacad]

Ok...  Have created the AE as suggested.  In fact, took the opportunity to convert another serial device to that format as well.  The third device was already configured that way.  As I mentioned, I have used that method before, just not by that term.

Since that change, the error has popped up once yesterday and once again so far this morning.  And still, once it does, all my serial communication is hosed and the system has to be rebooted.

So is this still a LV issue or could it be connected to the addon serial IO card that I am using.  I mentioned the brand/model in the first? post.  I tried to get a more mainstream brand as I had tried an off brand at one point and had dismal results.

I have attached the modified vi I am now using for the stepper control. (includes a couple additional vi's that are used inside it to generate strings & a typedef).  I am using the Init case once during the initialization of the system.  I use the Close case only once when exiting the application.  At all other times, I am using only the Write case.  If there is a reason to stop the process during assembly, the Kill case can be called which simply sends a kill/stop string to the stepper control. This rarely happens and has not been used when the error occurs.  There are a couple blank cases I made for future use so I can use this as a template for other projects.

The last few times, the error is showing up on the third Write of the assy sequence. This after completing dozens of succesfull assembly sequences. I am tracking this by placing error cases at the end of each step in the sequence with booleans in each error-true state so I get a true for the particular step that generates the error.

I have added a ton of probes this morning to see if there is anything else in the code the comes up unusual when this occurs.

Note that I have left the Termination Character Enabled set to True in the newer code though it was False in the original code.  Any detriment with that?

Any benefit in adding a Clear Buffer just before the Write to make sure there is not some anomalous character that gets thrown in at the front of the string?

Just need to get this behind me.

Thanks...