Siglent Strange VISA Behavior

[Andrew_F]

So, I started playing briefly with I/O trace.  And I think that should help.  However I have another bit of information that might be of help and it brings along a new question, which my just need to live in a new post.

I just performed a firmware upgrade of the devices.  The firmware WAS current until yesterday.  The firmware adds a new command to the device and I doubt is related to this issue.  Installing the firmware was an uphill battle as even when I connect the instrument to the PC, sometimes it will appear in the device manager and sometimes it won't.  Now I'm into a new land of confusion and I wonder if I breezed past this part when I first started using these devices.   In the windows device manager I see that the device actually comes up as an IVI device.  I am not familiar with IVI.  I am now starting to read into it.  So, I'm wondering at this point if I'm having some sort of IVI conflict or if it is involved somehow.  Up to this point, I figured I was just using a simple VISA call to a device like I've been doing forever.  Our company has a lot of older equipment dating back to the 70's and 80's and I started out using GPIB VISA Calls to communicate with equipment.  I've used USB RS232 converters, and a USB-GPIB converter from Prologix.  In general, I basically just plugged it in, and in certain cases had to manipulate things like end of line characters, or such things.  All of which made sense.  I have used other equipment very briefly which just plug in USB directly and I noticed the VISA resource address looks different...something like USB::blah blah blah::blah.  I thought it odd, but again I was still just using the same VISA vi's to perform my communications.  The project library instrument drivers offered from Siglent look just the same as all others.  However, I do not place these into the instr.lvlib folder of my installs due to source code control and adding these devices to a shareable library with other developers....but...I noticed that I did have the Siglent library in the instr.lvlib folder.  However, I do not make any explicit calls to this library.  In fact, in the code that I am writing using this software, I use the copy of the library that is in my project folder and make calls to this location.  I do not reference the instr.lvlib folder in the LabVIEW programs directory.

I noticed two VISA things installed... 

VISA Shared Components 5.6.0

VISA.NET Shared Components 5.6.0301

and IVI

IVI Shared Comnnponents 2.3

and .NET

Microsoft.NET Framework 4.6.1

I am also using LabVIEW 2015.  I'm just trying to throw as much information at this problem that I can.  Keep in mind that the original 'problem' is that when I tried to add open/close to the communication routine, the device would stop responding.  I've noticed also that when this occurs the device dissappears from the device manager.  Normally I'm used to seeing COM Ports, but with these power supplies, they come up under "USB Test and Measurement Device (IVI)".  Now to describe the next part...

I was having trouble (and I thought it was due to a USB Port expander) getting the devices to connect to my PC.  So, I would fiddle around with different USB Configurations until all my devices were connected.  I'm simultaneously connecting 5 devices.  Three Relay boards and two of these Siglent power supplies.  In the initial example above, all of these devices were connected.  However, none of the other devices were being 'talked to'.  I was simply using that single VI and running it.

After poking around a bit these last couple days I've noticed that when I would plug in the device sometimes it would just come up as an unrecognized device.  Now, since the firmware update, the device repeatedly drops in and out of the device manager window.  Signal Express now spontaneously loads as well....I've never even used signal express before.  So, things have gone from strange to worse.  I am now going to investigate this issue on a different system.  

In conclusion...where does the IVI driver live?  Does IVI have to live in the instr.lib folder of the LabVIEW directory?  Where do I go from here?...and I'll post more when I know more.  whew!  That was exhausting.  And I think it's an overload of information for this post.

[Andrew_F]

Okay, I have now ran the testing again, using a different computer.  I have also used I/O trace.  I'm not going to bother to share the actual VI, as this can be built very easily...there is nothing tricky in here.  Those 'timer' looking VI's are simply the millisecond wait.vi wrapped up with an error in and out to sequence things...there is no error 'handling' inside, what comes in goes through and out.

So I have repeated the behaviour.  With 100 milliseconds between each VISA call, the instrument will respond to an "ON" message.  I then waited a few seconds and ran the vi again, this time switching to "OFF" message.  A few seconds later I ran the VI a third time using the "ON" message...this time, no errors are reported from the VISA Calls, and the instrument stops responding.  I have taken notice of the device manager and the IVI device is still there.  I can restore communication by executing a simpler VI with nothing but the VISA Write twice.  The second time the device responds to the command and I'm back up and running.  I can now issue TWO more commands of ON/OFF with the open and close's back in the sequence with success and then communication is lost again on the third attempt.

So here's the sequence...

Issue 'ON' with open and close --- device receives command, device is on

Issue 'OFF' with open and close --- device receives command, device is off

Issue 'ON' with open and close --- device does not respond to command, device is off

Issue 'ON' without open and close --- device does not respond to command, device is off

Issue 'ON' without open and close --- device receives command, device is on

Issue 'OFF' with open and close --- device receives command, device is off

Issue 'ON' with open and close --- device receives command, device is on

Issue 'OFF' with open and close --- device does not respond to command, device is on

Issue 'OFF' without open and close --- device does not respond to command, device is on

Issue 'OFF' without open and close --- device receives command, device is off

I then repeated the test and inserted a 1 second delay between the commands.  I executed the same scenario and the same result occurred.  So, I'm back to what am I missing?  Is this just a strange happening with the device itself?

Another point of interest is that I also performed a write-read test with open and close...and this one performs perfectly well.  So here's how this was just tested...the device started out in the 'not communicating' state.  I ran this vi 3 times.  The first two times I received an error, -1073807339 which is a timeout on the read.  On the third run all errors were gone and the instrument started responding to my *IDN? query.  I can even run this in continuos mode without issue.  I'm totally flummoxed at this.

[Jorr-El]

Hi Andrew_F,

Here are some additional resources to help you understand more about IVI, VISA, and controlling your device with LabVIEW.

Have you tried running LabVIEW example code? Here are some examples that you could try, and see if you're seeing the same behavior with them:

Help>Find Examples...

Hardware Input and Output

•Simple Serial.vi

•Serial Port Monitor.vi

•Continuous Serial Write and Read.vi

The IVI driver is it's own software, which you will be able to see in your Programs and Features. The IVI drivers are separate from LabVIEW, and do not 'live' in the instr.lib folder.

Here is the IVI Compliance Package readme:

http://download.ni.com/support/softlib//ivi/ICP/ICP%2015.0%20Readme.html

I've also attached the driver from Siglent for your device. This driver also comes with example VIs that you can use to pattern your VI after in order to control your device. A lot of these problems that you are seeing may be incident to how the Siglent device responds to commands, and since they already have a nice driver to use in LabVIEW, you should be able to use it and figure out how they configure their VISA commands.

I've included an image of what one of the example program's block diagrams looks like

Hopefully these will give you some guidance and context for how the code is written and architectured to communicate successfully with your device.

[Andrew_F]

Thanks for the reply.  And that looks like a nice little VI you've built there.  I'm not having any issues programming the devices.  Once a communication channel is up and running I have no issues.  Their source code is really quite simple, and I really just built my own from scratch because I do a lot of logging and error checking.  The issue I have is when I include open/close into the routines.  It's really a little gremlin that has made its way into my life.  I've tracked it down in this case to the most simple version I could come up with....open-write-close.  Once I try this very simple method, things break down.  It has just blown my mind.  I've come a long way with LabVIEW these last 5 years and I primarily use it to communicate over all sorts of interfaces...GPIB/Ethernet/USB/USB-GPIB converters/RS232/USB-RS232...and I've seen some interesting sneaky things that you have to do with ports and termination characters, and wait times, and timeouts and all the 'good stuff'.  But...in this case, I can't figure this one out.  I might even try this with a different programming language to see if it's something to do with LabVIEW's VISA.  But I doubt I'll have the time to investigate too much further with this problem.  It could be that the Siglent end of the deal is just not up for the challenge, but when this happens I get no indication that anything is wrong.  No errors.

[Jorr-El]

Hi Andrew_F,

Just to clarify, I didn't build the VI shown above. That's one of the VIs that Siglent built for this device that's included in the device driver. I pointed this out because maybe there's some way that they're configuring their ports and sessions to avoid strange behavior like this, and it might be useful to see if there's any extra steps or configurations that they implement because of the device itself.

As for why you're seeing this behavior, it baffles me as well. Your simplified code looks like it should do what you want it to - open a session, write a command, and then close - and it should work every time. It could be that the Siglent device doesn't respond as robustly to these types of simple communications or uses some other configuration, which I thought could be contained within the driver code.

Initialize VI:

Inside Siglent Send Command VI (custom VISA write VI): 

I think it would be worth seeing if you formatted your queries the same way or if you tried the pre-packaged VIs to see if this behavior can be replicated. Maybe it is just the hardware behaving strangely, but it could give you some more clarity to try the driver example code.

[Andrew_F]

You know, now that I look again at it I'm amazed...and I'll have to test this...they throw a new line at the end of the commands!  If that's what's gumming up the works then shame on me.  They do not do any port configuration that I've seen. I'll try to perform these tests again and see if that new line character clears up the communications.

[Andrew_F]

Sadly (and to my actual relief), the line feed at the end of the command had no effect.  The hangup still exists.

I considered that perhaps this device is just sending a response no matter what, so I placed a VISA read after the write...the instrument does not seem to be responding, and I get a timeout error after the read node.  Interestingly though, the communications does NOT break down.  The routine is this  open->write->read->close.   I can run this piece of code repeatedly and the instrument responds to the command every time.  So, add that to the confusion.  

Looking more closely at the example vi's in their library, i notice that EVERY command whether it is a write or a query, is followed by an error query.  So perhaps the 'read' in my modified routine has something to do with it, even though it responds with nothing.  I'll have to perform an IO trace and see if that shed light on anything.  I did run the VI out of the example posted above and it runs without hanging up.  I even modified it so that the loop only executed once and then ran it over and over again without problems.  No closer to understanding this.

[Jorr-El]

It could be that the buffer isn't being flushed in between commands, and the error inquiry and reads are effectively doing this every time. At least now you have a code pattern that doesn't hang up like you were seeing before, which you can use to modify your own code.

[Andrew_F]

If that were true, wouldn't I see some sort of information with a visa read operation?  I'll play around some more trying to kick it out of the locked state without performing some 'uneccessary read' operation.  Of course this does show that by querying the device I can indeed open and close the visa session, but I'm just not satisfied yet as to why this occurs.  🙂  I'll update further after more investigation.

[Andrew_F]

So, I'm still baffled by this whole opening and closing ports.  This might be getting off topic, but I'm returning to it because there may be insight into this weird issue.  

I've been playing around with IO trace and I was expecting to see a call to VISA open when performing a simple write operation.  The simple block diagram and IO trace are below.

What is shown is 8 commands sent.  All commands were received and processed by my device.  I even sent a command called "GARBAGE" to see if communications would break down, or an error thrown.  The device "beeped" at me and had no trouble accepting the remaining commands (which were all output voltage changes).  

If I don't explicitly open a session, then when was this 'session' opened?  

And as I wrote that question, I found an answer.  Having IO trace active I exited the labVIEW development environment and voila, I saw a call to viClose().  I then opened the simple write VI that I created.  The VISA address was set as a constant on the block diagram and when the block diagram was opened, voila, a call to viOpenDefaultRM().  Close the VI and the viClose() is called.  So, here's a revised question then.

If even "seeing" a VISA session control on the block diagram/front panel (it applies if it is a control on the front panel), calls a viOpen session, then what is the point of the visa open vi?  And what affect would 'opening' a new session have?  Somewhere in this confusion is the answer to why explicitly closing this session sends everything haywire.