Siglent Strange VISA Behavior

[Andrew_F]

I am puzzled by VISA communications.  Everything I've read always talks about opening and closing sessions when "done communicating".  This problem is one that I've faced over and over and I always revert back to just allowing LabVIEW to take care of it for me.  So, here goes:

I've been recently communicating with a Siglent SDS3303C power supply and I'm getting such strange behavior.  I finally dumbed down my communications to this simple routine:  Open, write, Close.  What is not shown for simplicity is that I wrapped a case structure to bypass both the open and close section of code.  If I ignore both the open and close functions I can communicate all day long without any problems.  But, that's not how I originally designed the routines.  I originally wished them to perform such as the case below.  Where I would open a session, communicate, and then close the session.  So, here's where it gets odd.  If I use this method shown below I am able to send a command.  The VI finishes execution with no errors.  I send a second command, the VI finishes execution again without errors.  The third time around, all communication fails to work.  And I still receive no errors.  At this point I'm in a state of no communication.  If I remove the opens and closes (actually opens seem to have no effect on this), it takes TWO runs of the VI before commands sent begin to be received by the instrument.  I've also tried Asynchronous and Synchronous communication (though I doubt that would matter in such a simple case.)

So the question is why does this occur?  What tools can I use to diagnose what is happening?  Why does opening and closing cause such a ruckus?  And why is it on the THIRD attempt that the communication finally breaks down?

I have a delay inserted between each operation and the timing seems to have no affect.  I've placed delays in between each operation between 0 and 10 seconds (the number is in milliseconds).  How can I dig further into this to discover what is really happening?

And just to vent...Why on earth should I ever bother with opens and closes?  I mean, they just seem to cause me nothing but headaches!...Don't answer that.

[Wolleee]

As far as opens and closes, you need to open the com to take control of the resources and close so that you free resources so other programs can have access to the COM. Typically you will open a resouce, perform all of your interaction with the device, then close the resource. If you open and close the resource rapidly it can cause issues, as well as reduce effeciency.

A few questions:

Its a little odd you have a consistent error on the third attempt, but what is the error?

What are the configuration settings for this port?

Do you have a manual for the communication protocal?

[Andrew_F]

There is no error.  the device simply stops responding to communications.  For example, I can consistently send commnands to this power supply to change the output voltage from 1 to 2 to 3 to 4 ....all day long.  As soon as I add visa open's and close's to the routine, communication breaks down after the second close attempt.  No error is returned throught the VISA vi.  The device just stops responding.  When I just run a simple command with only the VISA write, communication restores itself after sending the command without the open/close (it might happen on the second attempt or third attempt, but it restores with no problem.)

The port settings are not really importatnt as far as I can tell in this case...due to the fact that I can communicate successfully without ever changing port settings like termination character, baud rate...whatever.

I assume you're asking about the manaul for the device I'm communicating with?  I do have a manual, and it is very limited.  There are about 12 different commands that can be sent and received.  

I do not have issue with controlling or talking to the device per-se.  The problem is when I try to implement VISA Opens and Closes that 'everyone always says to do'.  I've been writing software to communicate over GPIB, Ethernet, Serial, USB for a few years now, and I'm just getting frustrated because when I try to implement Open/Close routines, I get stuck at what seems to be the most basic level.  

I'm trying to get a grasp on what is actaully going on.  I have just started to read NI-VISA's manaul, which seems to talk about their implementation of the VISA protocol.  Most of it talks about functions which look like C code.  How do I peek under the LabVIEW hood to see what's actually going on.  Or what other resources should I be learning about?

[Wolleee]

Can you post the code you are having the issue with? Also in this particular application is gpib, USB..? Also if you can post the manual it might help to diagnose the issue.

im no longer at my desk but I will take a look at it tomorrow. 

[Andrew_F]

I'll post a manual tomorrow.  The code is the picture...there is no other code.  The application is USB.  The VI with the watch on it, is just a millisecond wait VI which I wrapped error in and out to so that I can put it inline with the dataflow.  The remove errors are there just so that each VISA command will execute without skipping due to any incoming errors (which there aren't any anyway).  Just to reiterate, I can successfully communicate with the device as long as I do NOT perform any VISA open or close at the start/finish of the VI.  This snippet of code is all there is.  I am sending a command of something like "CH1:OUTP 5".  No carriage returns or linefeeds.  The commands are correct which you can see when I post a link to the manual.  It's not an issue with talking to the device, but rather an issue when I open the port and close the port when finished.  This single VI will cease to communicate when I perform an Open->Write->Close.  The only thing that changes between success and failure is when I use Open and Close....if I run this single VI with ONLY the VISA Write, everything is fine and dandy.  

I appreciate the feedback, and I hesitated to post this because there is such a large proliferation of "I can't communicate with x device...please help".  I'm just trying to understand what is gumming up the works when I try to incorporate the 'proper' opening and closing of the session VI's.  No other code is executing in the system.

[cymrieg]

Run NI I/O Trace this should shine some light on the issue

[Wolleee]

NI I/O trace will probably help, but ive got a few suggestions and questions.

1. You are using USB, but i dont see you configure the port which means that you are using the defualt settings for visa, maybe that "works", maybe not.

2. Are you running the application in single run or continuous run when you run it 3 times?

3. On the 3rd execution does the VI complete or pause in the middle?

4. Can you operate the VI in highlighted execuation and see where the vi fails?

5. Are you using any RS232 converters?

6. Do you receive a response from the hardware that lets you know the command was received correctly?

Finally a manual would really help get the labview portion of this communcation setup.

[Andrew_F]

Here'a  link to the device manual I'm working with

https://www.circuitspecialists.com/content/135109/spd3303c_manual.pdf

1) I am indeed using the 'default' settings for visa.  

2) I'm running this vi in a single run mode each time.

3) There is no pause or any indication from LabVIEW that something is wrong (no errors)

4) Highlighted mode doesn't shed any light on the problem as there is no indication that there is a problem.

5) I use no converters, it's usb from the computer to usb on the device

6) There is no response from the instrument that I know of...other than actually querying the device in some manner.  I do intend to add much more checks in the future, but for now I'm more concerned with why the communication breaks down.

NI I/O trace seems to be the answer I'm looking for.  I found a similar post which referenced I/O trace.  As I understand I/O Trace I should see all of the low level stuff going on behind my back, and that's what my question is really all about.  I'm flabberghasted that I've never heard of I/O trace before.  I've been doing this for 5 years now!!!  

Most other devices have a LOT more information on the communications.  A lot of my work has been using Prologix usb-GPIB converters to communicate with GPIB devices...Which requires me to pay particular attention to special characters in the command sets as well as termination characters on reads and writes.  But that's a whole different story indeed!

Great feedback on this issue.  I'll post with some updates as they roll in.

[AnalogKid2DigitalMan]

Does their EasyPower software work, have you tried their drivers (if any)? Any firmware updates?

-AK2DM

[Andrew_F]

I have not used their easy_power software, or tried a firmware update, or looked for specific drivers for their communications.  There might be drivers or a firmware update.  As far as using their software goes in general I usually skip any manufacturers software as this usually prevents me from interfacing to it through labview and hence using it for hands off automation.  They do have labview code which is what I base my code off of.  I've not been able to spend time these last two days working on the issue as I've just removed the open/close vi's from my code and it is now fully functional.  I do intend to revisit this problem looking into it with I/O trace as I expect to see what's happening behind the scenes and hopefully this gives me insight into the problem.