Serial Issue with "new" version of LabVIEW

[dblk22vball]

I am getting very frustrated trying to figure out what is causing me issues communicating with a device over a serial to IR device and using LabVIEW.  I am working with NI directly on this issue, but I thought that maybe someone on here might have had a similar issue and were able to resolve it.

 

We are using a serial port (DB9) to IR head to communicate with devices in the test nest.  We have a system that was done originally in LV 2009, and it works just fine.  When we decided add additional test racks, I wanted to re-use as much code as possible, but of course there were some new features we wanted to add.  I "copied" (re-created the LV 2009 IR communication vi) in LV 2012 at the time.  I tested the vi on the development machine (laptop with docking station so it had a "real" serial port) and it worked great.

 

I then built the .exe and put it on the test rack.  We were unable to communicate with the UUT.  But if we restarted the test program, we could then talk to the UUT just fine.

 

So then I replaced the 2012 IR vi in my program (no other changes) with the 2009 vi (exactly the same just one was created in 2009 vs 2012) and rebuilt the .exe.  When tested on the rack, no program restart required, IR comms established right away.   Huh???

 

I adding all sorts of logging to see where (if) I was getting any errors on the test rack (logging the error cluster after configure serial port, flush buffer, read, write) and the only error I am seeing is the VISA Read timeout error when it does not get a response from the UUT.

 

I have made sure that VISA and LV runtimes are the same between the test rack and my development machine.

 

Windows 7 Development Laptop with docking station (development environment or running exe) - Serial IR head, USb to Serial adapter to Serial IR head or USB IR Head = Communication with out a program restart using the 2012 vi.

Windows 7 Test Rack touch panel PC (runtimes only, running exe) - Serial IR Head - Requires program to be restarted when using 2012 vi.  With 2009 vi, communication established without program restart.

Windows 8 Personal Laptop (runtimes only, running exe) - USB to serial adapter to Serial IR head or USB IR head - Communication works without a program restart using the 2012 vi.

 

 

There seems to be something different in the way VISA or the code behind the vi acted in 2009 vs 2012 (I have also tried 2014) in regards to the serial port.

 

Running NI IO Trace so far has not yielded any "ah, ha!" differences.

 

EDIT: Attached files.  Rev 242 is the version that does not work (2012/2014), Rev 243 is the version that used the 2009 IR vi.

IR_WakeupAndTransmit LV 2009.vi

serial trace files.zip

Edited March 19, 2015 by dblk22vball

[bbean]

Can you attach your 2009/2012 VIs and NI IO Trace logs?

[dblk22vball]

Can you attach your 2009/2012 VIs and NI IO Trace logs?

 

I attached the files to the first post.  COM1 is where the IR comms happen.

[bbean]

I can't really tell from the NItrace or code.  Do you have the manual that describes the wakeup protocol that you could also attach?

 

Is the touch panel a "real" serial port  or a USB to serial converter?

 

One problem I've had in the past with USB comm (or USB->serial com) was with the OS sending the USB ports to sleep.  Not sure if it could/would be able to do this on a "real" COM port.   Check the Advanced Power Settings in Control Panel\All Control Panel Items\Power Options\Edit Plan Settings and disable this everywhere.  You may also have to disable something in the BIOS.  The worst part about the USB sleep feature is that the more efficient you make your program the more likely the OS is to power down the USB port. 

[ShaunR]

In the "one that works" the VISA timeout is 10 secs, whilst the one that doesn't it is 200ms.

[dblk22vball]

I can't really tell from the NItrace or code.  Do you have the manual that describes the wakeup protocol that you could also attach?

 

Is the touch panel a "real" serial port  or a USB to serial converter?

 

One problem I've had in the past with USB comm (or USB->serial com) was with the OS sending the USB ports to sleep.  Not sure if it could/would be able to do this on a "real" COM port.   Check the Advanced Power Settings in Control Panel\All Control Panel Items\Power Options\Edit Plan Settings and disable this everywhere.  You may also have to disable something in the BIOS.  The worst part about the USB sleep feature is that the more efficient you make your program the more likely the OS is to power down the USB port. 

 

This is an actual serial port.  I have already changed all the Power settings for the USB devices to always be on, as that did cause issues.  Thanks for the suggestion.

 

The manual says that you are supposed to send 0x00 for 1 sec, followed by the sync byte 0x95.  The UUT will then acknowledge it saw the "wakeup" string with a 0x4B + 4 other bytes.  There are no termination characters with this protocol.  I added timing vi's to measure how long it too to send the 0x00's, and reached the conclusion that 960 for the FOR loop count worked out to ~1 sec (see the block diagram of attached vi).

 

 

In the "one that works" the VISA timeout is 10 secs, whilst the one that doesn't it is 200ms.

 

I apologize I forgot to put that in the first post.  NI has commented that the VISA time out is "consistently inconsistent", ie it will vary.  I have played around with different timeouts from 200 ms up to the 10000 ms and still the same result.  BTW, the UUT will go back into sleep mode within 250 ms after a wakeup command if no other commands are received.  So waiting 10 seconds for a response from the UUT would not work in the long run.  If you look at the "works" vi I attached above, the timeout is set to 200 ms initially, and then after the wakeup is received the timeout is reset to 10000 ms.

[bbean]

The manual says that you are supposed to send 0x00 for 1 sec,...

What if you decrease the frequency of the 0x00 eg.  have a 1ms wait between each 0x00 send and use a while loop that exits after 1 second of elapsed time (vs a for loop).  

[ShaunR]

Right click on the read and write primitives and select "Synchronous I/O Mode>>Synchronous".

[bbean]

Right click on the read and write primitives and select "Synchronous I/O Mode>>Synchronous".

2nd this

[dblk22vball]

Update: It may be solved.  I will continue testing more next week (7:15 PM where I am at)

 

I had to uninstall all NI software, and only reinstall LV 2014 items.  Then I ran a Registry cleaner.  I also updated the Agilent IO Suite from 16.7 to Keysight (new Aglient name) IO Suite 17.1.

 

I also made the changes suggested above (Synchronous mode and 1 ms wait in the loop).

 

Thank you for your help.