LabVIEW hangs at RunVI invoke node in Watlow f4t Driver

[Chaulk]

Hello everyone, 

I only just started using LabView a few weeks ago to automate some instrumentation and, generally speaking, I have found it pretty good. I've also spent some time lurking on these forums and have found some of the posts very informative, so hopefully some of you could offer me some helpful advice as well!

I have been trying to communicate (using Ethernet) with an Espec climate chamber (which uses a Watlow f4t controller) with their Labview driver, simply trying to perform the following commands for a given profile:

- Start (Param ID: 79014, write: 1782)

- Pause (Param ID: 79016, write: 146)

- Resume (Param ID: 79015, write: 147)

- Terminate (Param ID: 79016, write: 148)

The driver essentially only provides 4 blocks to work with: initialize, read, write, and close. Using the write block, I can perform any of those 4 functions (start, pause, resume, or terminate) exactly once before LabView locks up. If I send the "Start" command, for example, profile 1 of the chamber begins as expected but all of LabView freezes; I am forced to use Task Manager in order to shut down the application (LabView's Abort Execution function does not work). 

Using the Highlight Execution function, it looks like the program stops at the following blocks within std_bus_write.vi:

As I've already explained, I am a novice with LabView; could anyone explain to me why these blocks may never finish execution? I've tried running the write call asynchronously (code attached, ignore the messy lines), to see if I could hack around the problem. But I basically ended up with the same issue. 

Thanks in advance for your help!!

PS - If I've posted in the wrong forum, sorry about that! Please just let me know where this should be posted.

[Ben]

Is that code that came with the driver?

If not try out the example that comes with the driver.

Ben

[Chaulk]

Hi Ben,

Thank you for your reply! Using the example code that was included with the driver (Standard Bus Labview Example.vi) was what I first tried, and was also when I first started having this issue; using the driver's READ block seems to work fine, but using WRITE always caused LabView to lock up (despite the command seeming to be properly processed by the chamber). The code I posted was just part of an attempt to debug the issue - I wanted to see if LabView would still lock up if I used an asynchronous call.

Is there anything that would cause an Invoke Node to hang perpetually like that? A VI setting or anything like that maybe?

Thanks again!

[Ben]

---

@Chaulk wrote:

Hi Ben,

Thank you for your reply! Using the example code that was included with the driver (Standard Bus Labview Example.vi) was what I first tried, and was also when I first started having this issue; using the driver's READ block seems to work fine, but using WRITE always caused LabView to lock up (despite the command seeming to be properly processed by the chamber). The code I posted was just part of an attempt to debug the issue - I wanted to see if LabView would still lock up if I used an asynchronous call.

Is there anything that would cause an Invoke Node to hang perpetually like that? A VI setting or anything like that maybe?

Thanks again!

---

If the example hangs there is little you can do in LV to fix it unless it is a problem with the LV part of the driver. All I can suggest is go back to the install directions and make sure you loaded the driver properly.

Why would LV hang?

If the driver uses a dll and the example code is calling the dll using the standard "Run in UI thread" LV would hang until the dll completes and if the dll is the root of the problem... well there you go!

Ben

[tyk007]

Well that Close Reference node isn't right anyway - the reference is being closed and, before or after this, then the last Invoke node is called. There are no constraints put on what order those two nodes should execute (ie dataflow) so that should be fixed at least or that the Close Ref is after the Invoke node. This wouldn't cause a hang however; when the bug asserts itself you would just get an error on the last Invoke node.

EDIT: Actually when I download the API I see that the picture you show is *not* what the Write VI looks like - the Close Ref is attached to the WatbusAttributes Property node, not the ILabVIEW reference wire. Make sure you revert the Write VI back to its original state so that you don't end up with the bug you have shown.

The API uses .NET assemblies rather than Win32 library dlls. When the .NET assembly properties or methods are called it consumes the current thread executing the code - there is no way to specify the execution system to run the node (eg. user interface) except through the container VI. In the API I downloaded, the VIs are set to use "same as caller" for preferred execution system so the UI thread should not deadlocked in this case unless the .NET assembly itself is attempting to interact with it.

I did notice that the Example VI makes use of the LabVIEW "Set Busy.VI" to change the cursor and prevent clicks on the VI which is not a great idea (as this can make the window appear to hang - this is what mine does since I don't have the hardware connected like you do).

My suggestion is to break their example down into smaller pieces. Or, better still, contact the supplier to see if they can help troubleshoot.

[Chaulk]

Sorry! I used the wrong file for a screenshot, good eye! I did do some playing around with the std_Bus_Write.vi, trying to gain insight as to what the problem was, and I took a screenshot of this file, instead of the original. This problem occurs with the original std_bus_write.vi. See another screenshot from run-time, below, which shows a little more precisely where LabView stops executing:

 

I've also simplified testing code (attached) as you recommended. I am still seeing the same issue with LabView failing to resume execution at the locations shown in the screenshot above.

Also, I'm not sure how important this is, but it actually doesn't seem like the entirety of LabView locks up; I could actually still open sub-vi's and can click the Pause with some UI response. However, clicking Abort Execution does not allow me to abort the application. Could this be related to .NET, as you suggest?

I am very close to simply writing a python script to do these commands, and just run it through the command line using LabView. 

I've emailed Watlow last week, and I've still not gotten a response. I will try emailing again, or calling soon.

Thanks again for the help and suggestions!

EDIT: So keeping the std_bus_write.vi block diagram open during execution makes the flow appear to stop at slightly different positions. I've included this below, in case it is at all relevant:

[tyk007]

I believe that running the VI with execution highlighting enabled forces the VI to execute on the user interface thread explicitly for many nodes, which is why, when it is enabled, it seems as if the VI doesn't actually execute most things in parallel. It puts you into a position where attempting to observe the behavior influences its results, just like most debugging in a way. To help with consistency you are better off using probes at various places in the dataflow to observe whether the probe is updated or not, giving you the information to determine where the block diagram is up to without the impact on execution that highlighting enforces.

You'll also find that once a thread crosses the boundary into the .NET CLR the Abort button / Ctrl-. may not work under all circumstances, depending on the implementation in the .NET assembly. If the .NET assembly code uses asynchronous or signalling primitives then it is possible that the currently executing thread cannot be requested to "abort"; in fact I believe that the abort will only work once a thread has finished executing its current "clump" of LabVIEW code assigned to it by the current execution system.

Without digging into the implementation of the .NET assembly (which you can do if you are so inclined, it is not obfuscated) your best shot is support from the supplier.

[Ben]

A question for you tyk007 !

I have not worked much with .NET but I do recall that there are different flavors of .NET.

Would you think that the wrong type of .NET is on the original poster's machine?

Would there be an entry in the System Event Logs associated with .NET errors?

Just asking questions...

Ben

[tyk007]

Always a pleasure Ben!

I assumed that given some aspects seem to work as described by the OP that it seemed unlikely that it was a framework or CLR version specific issue but maybe the OP can clarify what he has installed - he can find it under his installed programs (depending on his OS etc.)

Generally most .NET exceptions internal to the operation of the assembly aren't logged anywhere unless coded or configured specifically to do so; if they aren't handled by the .NET code at all then they just bubble up to the output; in this case LabVIEW reports them encapsulated in the error cluster under the generic 1172 code. Errors with loading the assembly itself would manifest during the initial use of the assembly (the first call), not later down the track so this particular case is something I would exclude for now without more knowledge of the assemblies internals.

That's not to say that it isn't possible for .NET code to "swallow" errors and not report them through some mechanism; it would be poor design to do so but entirely possible to deliberately or otherwise code in such a way.

Given that the driver exists at all with an example it suggests to me that the example worked fine on the original developers machine. So it is most likely either:

• Some sort of dependency on hardware or software that the original developer was not fully aware of or did not communicate to users of the driver.
• A hardware, configuration or connectivity issue that is not being properly reported back to the users of the assembly. Troubleshooting this would probably require some knowledge of the assemblies internals.

I had a quick look at the .NET code for the main assembly. It appears to dynamically load other .NET assemblies on disk in order to expose different hardware connectivity options (Usb and Serial assemblies). However the OP says that he is using Ethernet specifically so this is something that I would also put to the side for now.

[garciaj]

Hi all, I am experiencing the same problem. In fact I opened a new thread a few days ago:

https://forums.ni.com/t5/Instrument-Control-GPIB-Serial/Problem-with-write-subvi-in-Watlow-EZ-Zone-c...

Did you get a reply from Watlow? I think I will contact them as well to support your enquiry.