Watlow EZ Zone Serial VI causes GUI Lag?

[boulderjoe]

I'm having a frustrating issue with my VIs that I think I've narrowed down to a driver Sub-VI. The "read" SubVI/dll for Watlow EZ Zone controllers seems to cause my LabVIEW GUI to slow down and lag. For instance, if this subVI is running and I go to browse the any of the main LabVIEW pull down menus (file, edit, view, etc) they lag to pull down and switch between them. The lag carries over to other GUI operations (clicks, text entry, etc). Any ideas? I've attached screenshots of the two VIs. I'm also using an FTDI USB-rs485 adapter with VCP drivers. I've tried setting the execution of both VIs to instrument I/O but doesn't seem to help.

Thanks,
Joe

[Ryan_S]

Hey Joe,

        What's your CPU usage while running the VI? It sounds like the "read" subVI may be using a large amount of the CPU and causing the front panel controls to lag. From looking at the Block Diagrams you posted, the "read" subVI is going to try and run as fast as the processor will allow it. If you insert a Wait function into the For Loop, While Loop, or both, and set it to 10 or 50 ms then this should give the CPU some breathing room and allow it to keep up with the GUI. If this doesn't change anything, then it may have to do with the dll itself. Hope this helps!

--Ryan S.

[boulderjoe · Accepted solution]

Thanks Ryan,

I actually just fixed it this morning by myself. Turns out it was a "call library function node" that was left by the vendor in "run in UI thread" mode, instead of "run in any thread"

Much better now. 😄

[bzadler]

Joe,

Thanks for the tip.  Since you fixed your issue, I am going to hijack your thread!  I have the exact same hardware as you - FTDI usb-485 cable connected to a Watlow EZ-Zone controller.  By any chance have you tried running two instances of your UI at the same time? In the Labview environment, I have 2 UIs called RIGHT and LEFT which appropriate their own halves of my monitor. Each one talks to a Watlow through its own usb-485 (and its own COM port).  They work fine in Labview, but when I turn them into applications (.exe), they crash 100% of the time with the error shown in the screen grab.

Exception: Access violation (0xC0000005) at EIP=0x07F05750

This only occurs when I establish communication with the watlow controllers, so I am thinking there is some crosstalk between the applications, even though they are built from two separate projects with their own VIs and EZ-Zone.dll dependencies.

You are the only person I've seen with the same hardware, so I thought I throw the question your way.

[Ryan_S]

Hey bzadler,

      A few comments/questions:

1. Since the error doesn't occur until you establish communication with the watlow controllers, it sounds like the issue may be with the dlls. Make sure all of your Call Library Function Nodes are set to "Run in any thread".

2. Have you tried temporarily disabling your firewalls/anti-virus programs? These programs can sometimes interfere with the executables.

3. Can you run a basic executable? This will help us rule out any issue with the application builder itself.

4. Can you run the executables individually?

5. Have you tried running the executables on a different computer?

6. What OS and version of LabVIEW are you running?

These details may help us narrow down the source of the error.

--Ryan S.

[bzadler]

Hi Ryan,

Thanks for the help. Here is what I've observed so far.

1. calls to the dlls are all set to "run in any thread'.  that got rid of the lag issue when read/writing
2. haven't tried disabling antivirus/firewall, I'll try that next.
3. making executables is working fine. I've been doing it for a year.
4. I can build and run the executables individually without any signs of error, both on the development maching (as labview VI or as an executable)
5. I am installing the executables on a different computer.  Several in fact, as I am building 4 of the same system: 4 computers running 2 watlow heater controllers each, as well as 2 9219s for pressure guage and temperature logging.  The executables, only individually, work fine on the other machines.
6. I am running windows 7 pro, labview 2011 (August) on the development computer.  The deployed computers are running windows 7 home.  I've created an installer and put on the labview 2011 runtime, NI-MAX 5.0, NI-DAQmx core runtime 9.3.5, NI-DAQ config support, NI-VISA runtime 5.1.

Last night I discovered that I can produce the same error/crash while running both in labview development.  So it is not soley due to the conversion to an application.  Also, it doesn't crash 100% of the time. To add to this, the first time I try to run the second executable, it always crashes.  If I try to run it again right away, viola!, everyone seems happy. 

Brian

[Ryan_S]

Hey Brian,

      This sounds like some sort of conflict issue with how the dlls are reserving resources. Were you able to try disabling the firewalls and virus scanner and, if so, did it have any affect?

--Ryan S.

[bzadler]

Ryan,

after much much work, I can trace one issue to the individual VIs trying to read/write at the same time being A cause for crashes. It may not be the only cause. Making the VIs reentrant makes them crash as well. The only way I can successfully talk to both watlows semi-simultaneously, is to talk to them both from the same subvi where I read/write to one, then the other.  I can make this work, but it is a lot of rewriting for the final product to merge the two now-separate programs.

[Ryan_S]

Hey Brian,

      From your description, the cases that cause LabVIEW to crash (2 separate executables, reentrant), and the case where it does work (using a singular ddl call), this all points to an issue with the dll itself and the way the dll is calling and reserving resources. If the dll is reserving certain key resources that cannot be accessed by another call to the dll or other programs then your options may be limited to running all communication through one call to the dll and its subVI. Hope this helps!

--Ryan S.

[m3rv89]

Thank you. I am facing this same issue and solved.