I decided to write on this forum as I am a Labview novice and I would like to understand if the idea in my head could be translated into a language suitable for this programming environment.
What I would like to do is define a VI that fully handles communication over an RS-485 line within my project. Specifically, it should have a queue in which to queue all the communication requests arriving from the various parts of the program, which should be processed, as master, in the order in which they arrived (FIFO).
My doubt concerns the management of the replies that would be received from the various slaves and, in particular, how I could redirect them to those parts of the program that generated the respective requests.
Thanks in advance to anyone who tries to clarify these doubts
Your request is quite possible, but you need to be able to understand advanced LabVIEW Design Patterns/Loop Synchronization and so on to achieve this.
Please go through basic LabVIEW, if you are familiar with basics you can go through advanced design patterns few are shared here.
It is definitely do-able, and LabVIEW has some features that make it a little bit easier to develop and to conceptualize (and walk someone else through your code) than many other conventional text-based languages with which I'm familiar.
The first thing to do is to consider a "high level" description of "What" you want your code to do, without worrying too much about "how" it does it. I gather, from your brief description, that you have a Main routine that, at various times, sends requests to other entities (which might be other computers) that work "at their own pace" and, at some point, return results back to the Main routine.
Let's conceptualize two Worker routines, W1 and W2. How does the Main routine know how to communicate with each Worker? Often the Main routine has an "Address" for each Worker, and sends instructions/requests to the desired Worker's Address. But what happens when the two Workers want to respond? They are both sending to the same Address (the Main routine), so they may need to "encode" their responses by identifying who is sending. When the Main routine gets a Message from a Worker, it can identify (from the Message) if it is from W1 or W2, and dispatch it accordingly.
It gets even better. LabVIEW can spin up independent "Listeners" that check every so often (maybe 100 times/second or faster) for any message from a pre-assigned Worker. If not, go back to sleep and ask again, otherwise get the response and "do what needs to be done".
First of all thank you for the time you are dedicating to me.
The situation is a little different from what you assumed. In particular I'm trying to develop an application that interrogates devices installed on an RS-485 line, communicating with the Modbus protocol.
Being that the different requests generated by the Master, which would be the PC with my running App, could be generated from various points of the program, running simultaneously, I would like these to be queued in a single queue and that a specific part of the program took care of sending these requests in the order in which they arrived, also taking care of collecting and sorting the replies.
Once I have the answers, what mechanism can I implement in this specific subVI so that it knows which part of the program to return the received information to?
Thank you so much
I think I'm getting a better idea of the "model" of your code. Am I correct that you have multiple "Workers", coded as Parallel Loops running simultaneously with the Master, and exchanging information through a mechanism like Queues or Messenger Channel Wires? Is it also the case that Workers can connect with and do ModBus (with which I have no familiarity) communications with a unique Target)? Then why not let the Worker manage not only the sending of requests/commands to the Target, but the receipt of responses/data from the Target, doing all of the ModBus stuff, and passing "processed" data back to the Master when appropriate? This (it seems to me) keeps the Master free from worrying about the "messy details" of managing all the responses and sending them back to the appropriate Worker.