"MB Ethernet Slave Demon.vi" connection lost when opening a windows dialog in my application

[Joe38]

Hello everybody,

I am currently working on a LabVIEW application which communicates with a PLC using a Modbus protocol (with an ethernet cable). The PLC is the master and the PC is the slave.

The code is base on the Modbus examples from LabVIEW : "MB Ethernet Example Master.vi, MB Ethernet Example Slave.vi, and MB Ethernet Slave Demon.vi". It is not the first time that I am using it.

But I recently discovered a problem. In my application, I have a pop-up with a button which allows to open a windows dialog in order to select a results file.

When this windows dialog is opened, the "MB Ethernet Slave Demon.vi" hangs (I put a counter in it to see what happened and it stops counting the moment the dialog opens), then when I close the dialog, the counter continues to count, the array of the connection IDs is empty, and the number of connection of the slave demon VI resets to 0. When the communication is re-established between the PC and the PLC (like 10 seconds after closing the dialog), the number of connection switch to 1, and the array of connection IDs is not empty anymore.

Otherwise, the communication works just fine. But not when the dialog is opened and this is an important problem for me because the user has to be able to open results file during the production which needs the Modbus communicates to work because it is the PLC which gives the orders to the PC to execute the production cycle.

Thank you in advance for your help.

[Jun']

Hello Joe,

It's pretty difficult to exactly understand your issue without a VI or some screenshots. Altough, it seems that your program is sequential with the opening of the pop-up Window actually blocking the thread. I may be wrong so do not hesitate to give more information.

I believe the solution to your trouble will be in the software architecture you choose and the way you handle an asynchronous flow.

I suggest you take a look to the producer-consummer model to allow your tasks running in parrallel.

Does this make sens to you?

I suggest you take a look at the exemples if you choose to implement this model as your architecture. Yours may not actually use an event structure but this will help you as the general architecture.

Have a nice day,

M-Junior

[Sam_Sharp]

The windows file dialogue is a UI/root thread/loop blocking operation - any VIs that run in the UI thread will be blocked from running until the file dialogue is closed.

So...

- You either have some code in your modbus handler that requires the UI thread (you can read about things that use the root loop here: http://www.labviewcraftsmen.com/blog/the-root-loop). Do you have any property nodes or anything like that in the loop? Can you highlight execution before the dialogue appears to see which VI is blocking?

or

- The modbus library itself is blocking the thread for some reason. If this is the case, I would look for an alternative library or modify the code (if it's an open library) so that it doesn't use the root loop. There are other LV modbus implementations.

Finally - you could try to find a way to avoid using the Windows File dialogue - provide users with a different method to load the results file.

Can you post your code so we can take a look?

[Joe38]

Hello, thank you both for your answers.

@Jun' : Your explanation makes sens to me. Actually, we always used the arcitecture shown in the screenshots in order to run two tasks in parallel. One for the screens of the application, and the other for the data acquisition, outputs driving, and PLC communication.

@Sam_Sharp : As you can see in the screenshots, I am running two things in parallel in my "Global VI".

IMPORTANT : I noticed that the issue also appears when I open a drop-down list in my application. The communication stops until I chose an element in the list.

Unfortunately I can't post my code. I hope the screenshots will give you a better look at my issue.

The windows dialog is triggered by an event in the "UI Mesure" of my "Global VI" while my PLC communication is running in the "ME Automate VI" of my "Global VI". The "PLC Grf VI" is kind of a state machine, first it initializes the PLC communication, then it reads/writes elements during all the time the application is running. If an error occurs, the PLC communication is closed, then initialized again, and so on.

When my issue occurs, my "PLC Grf VI" stays in the read/writes step (step 20) and the VI keeps running normally.

But when I check the "MB Ethernet Slave Demon" which is started in the "Init Comm VI", it seems like it is waiting because there is no connexion IDs found.

Thanks.

[Sam_Sharp]

Unfortunately I can't debug pictures and I cannot see anything obvious from the screenshots (except there's no data flow and lots of globals so plenty of opportunities for race conditions).

Did you find out which VI is blocking while the dialogue is open? The 'Run VI' method probably executes in the UI thread so that's one place where it might hold things up but it's impossible to tell without being able to see all of the code.

[Joe38]

The issue occurs in the "MB Ethernet Slave Demon VI" which is part of this library http://www.ni.com/example/29756/en/ .

I put a counter in the "MB Ethernet Slave Demon VI" as shown in the scrrenshot. This counter stops when I open a windows dialog in my application or when I open a drop-down list. Then when I close the dialog or chose an element in the list, the counter resumes.

I also put a counter in my "Run VI", and it always count, from the moment the application starts, until the application is closed.

About posting my code, it is not up to me. I will see if there is a way to post a lighter version.

[Sam_Sharp · Accepted solution]

If you think the the problem is inside the (old) NI Modbus library, why don't you use the newer one available on the tools network? Link is here: https://decibel.ni.com/content/docs/DOC-30140

Looking into a few of the VIs in the library, it uses VI Server methods like 'Run VI' which must run in the root loop, and as such will block while the file dialogue is open. I suspect the newer version of the library doesn't have this problem.

[Joe38]

Thank you for the advice.

I downloaded the last Modbus Library (I thought that the one I downloaded on the NI website was the last). I will let you know if it works.

[Joe38]

Thanks a lot Sam_Sharp.

I modified my code to use the last version of the "Modbus Library".

The issue does not occur anymore !!!