LabVIEW
Strange connection between right click menu and NI Modbus Library (?!)
I don't know if I am recalling this correctly, but it seems to me that activating the menu is a UI event that affects the UI thread. If the Modbus library is a dll that runs in the UI thread, it could cause problems. But again, I'm not sure if I am recalling this correctly or not.
Let me guess, you have created programs that talk to each other through Modbus?
In that case it is very understandable what happens. Modbus is a command response protocol. The Modbus master sends out commands and receives responses. The Modbus slave wait for incoming commands and then responds.
So your Modbus slaves are programmed to wait for commands and if there is no command, they will simply keep waiting until their is one then process that command and send a response.
Your Modbus Master works differently. It sends at some point a command and expects the slave to respond within a specific time. If your slave is programmed in such a way that the Modbus communication is happening in the same loop as your user event loop, then you get the problem you see. When your user makes a right click, the event structure is normally locked until the something is selected or the right click is ended. If in this time the Master sends your program a command, your receiving code can not execute since your event case structure in your loop is still waiting for the user to decide what he actually wants to do with that right click. After 5 seconds your Master says, drat something must be wrong and aborts with an error.
Quickest fix but hard to teach: Don't keep the right click menu or similar user interface actions for long periods of time active
Quick and ugly fix: Increase the timeout in the Master
Proper fix: Do not integrate the instrument communication in the same loop as your user event handling. Create a seperate loop that can happily keep working even when the user decides to keep the right click menu open for indefinite time. Use queues or other message based techniques to have your user interface loop send messages to the communication loop or vice versa.
Thank you very much Rolf, for taking the time to answer.
Yes, I have multiple "drivers" that are Modbus Slaves, and a main program (Modbus Master) that reads data from these.
I (tried) to design the Slaves so that Modbus communication is decoupled from the UI.
That part of the code is handled in a separate "Engine.vi" that the "Main.vi" starts at the beginning (call and forget).
In the Engine.vi I start the "MB Ethernet Slave Demon", that I don't know much about how works.
I write my data to the input registers, and I assume the Master queries these registers for it's slaves, as you write.
For the UI, I use the event "Shortcut Menu Activation?", but it doesn't appear to "lock" the code.
I can see other indicators update, and the state machine ticking away in the background.
But I'm certain that this is somehow related to Modbus, I just can't understand how.
If I disable driver "A" in my Master program, so that it does not attempt to read from "A", I will not get the problem when I right click in A's UI.
When I enable A again it will cause the freeze, due to "TCP Read.vi" giving the timeout.
Note that this issue is not just related to my custom right click menu, but also the default run-time shortcut menu.
Now I'm trying to understand if this is somehow connected to the "MB Ethernet Slave Demon.vi".
The way I've structured my code, I have my Modbus file in a shared common folder to all my programs.
The vi has two loops running. If I have nothing connected to my driver, and I bring up the shortcut menu, both loops continue to run.
If I connect my Main program to the driver ("# of connections" = 1) and now the shortcut menu actually stops the bottom loop (screenshot below).
It seems to be "MB Ethernet Call Wait on Query.vi" that locks up.
This .vi is "Non-reentrant", and has "same as caller" Execution System. Caller being "MB Ethernet Slave Demon" which has "Other2" set as Execution System.
All that "MB Ethernet Call Wait on Query.vi" does is call "MB Ethernet Wait on Query.vi".
This is a reentrant vi.
PS) I don't know if this is somehow relevant, but I just noticed that right clicking in the project explorer also triggers the issue.
I tried changing Execution System and Priority of "MB Ethernet Slave Demon", but this didn't make a difference.
I found this forum post which might be relevant:
https://forums.ni.com/t5/LabVIEW/MB-Serial-Slave-Demon-amp-Box-dialog/td-p/2860570
Also this from eehelp.com:
where the suggestion is to use a newer lib for Modbus. I belive I'm currently using this newer version.
I might try to post in this thread:
and maybe catch the attention of one of the active contributors there.
