From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
10-09-2017 06:20 PM
I just want to say, I don't want to come off as asking for anyone to do anything for me. I merely would appreciate anyone who reads my very general description of the project's goal and can perhaps help me decide on an overall general architecture to pursue. I think what's making this hard for me is that the last project I did, although not as big, I did indeed spend what I thought was an adequate amount of time planning only to realize that I had wished I had pursued a different strategy when I was 80% done.
In general, what I want to do is to be able to parse a "run" file that specifies various runtime variables, commands to be sent to a scientific instrument (in this case, a cartesian robot & some peripherals it will service in order to fulfill a set of processes to be performed on discrete units/widgets). All device com interfaces with the manufacturer's ActiveX interfaces. As an example, I would have lets say a config or XML file that will spell out which tasks, in sequential order, that the system must perform on a "unit". So it may be like
Step1: Pick unit 01 from storage
Step2, Place unit 01 on device X
Step3 Run program 4 on device X
Step4: Move unit 01 to device Y
Step5: Run program 1 on device Y
Step5: Move unit 01 from device Y to finished output station.
And basically as soon as unit 01 is done with step 1, unit 02 could begin step 1, and so on.
What's making this tough for me is I can't figure out whether something like a state machine or dynamic event style architecture would be better for working through the run file procedures. Then there is also the fact that the UI will also need to respond to user interaction even while running, things like Pausing, Resuming, Aborting, etc... Finally, the program needs to poll the devices to receive confirmation that a step has finished.
So in one sense it needs to respond to user front panel interaction, it needs to parse/process/perform the procedure listed in the run file, and it needs to poll the hardware for status & error messages to know when steps are completed.
My first thought is use a queued message handler for user UI and sequentially performing the tasks specified in the file. And have a state machine subvi that handles the polling and communicates back to the message handler as needed via a queue.
I'm a little concerned with how using a state machine would work for running through the procedures in a file. The steps will not be some fixed enumerated set. I'm having trouble with how to do that as I associate enums with state machines. What about dynamic events? I've not really had a need for those so I don't know enough yet to know whether that would be suitable.
But like I said, I'm gun shy about getting started after my most recent experience of deep regret over the architecture I initially began with.
I hope this was descriptive enough, I'm looking forward to any comments & suggestions.
10-09-2017 06:33 PM
Hi DoctorAutomatic,
I would probably use a JKI State Machine for this type of task. You may want a helper loop that will send commands to your instrument and poll it for updates. You could communicate to the helper loop with a queue, and back to the JKI SM with user events. User Events are similar to queues, but instead of using "Dequeue Element", the event structure will handle the event when it has a chance. Also, multiple event structures could listen for the same event, while you would only want a queue to be dequeued from in a single place.
If you really like QMHs, you could use the DQMH framework with a couple of modules like, UI, Test Manager, and Instrument. These would communicate via user events, but the DQMH scripting does all the legwork for you.
I will try to do a mock-up of the JKI SM idea for you if I get a chance.
10-09-2017 06:53 PM
This is an example of how you might add a helper loop to the JKI SM to do the instrument communication and polling. Now, you will have to decide what data type you need, I just used a string/variant cluster. You could create a different user event for different types of messages, or have the message be part of the data and then perform different actions based on that message. This is just to show you some of the elements, it will not run, I didn't wire all the errors, I didn't destroy the user event, but it could show you the big picture 🙂 Also, I used ctrl+alt+drag to make it smaller, so if you actually drag the code into LabVIEW a lot of the JKI SM stuff will be hidden behind structures.
10-09-2017 07:41 PM
Is there an official or widely regarded link for documentation on this JKI state machine? I'm interested to know the difference sbetween it and just a "regular" state machine is. I think i once used some JKI xml libraries years ago, that I believe I had to pay for, I their state machine an add-on that costs money?
Thanks for all the suggestions so far fellas.
10-09-2017 09:23 PM
The JKI State Machine is free and widely used. You can find info and tutorials here: https://github.com/JKISoftware/JKI-State-Machine
It is just a string-based state machine, that returns to the event structure when there are no more states to execute. The way I code it, is most things are called through a "macro" state, which is just multiple states strung together in a multi-line string. I find it very easy to debug and modify quickly once all my states are built. Sometimes when people pick it up though, they find it a little limiting. Like in your example you want to poll the instrument, which it is not that well suited for, which is why I suggest the additional loop.
10-10-2017 09:42 AM
I wanted to add, don't get caught up on the JKI SM. You can replace that with an event handling loop and a message handling loop if you are more comfortable with QMHs. The user event is optional as well, but is very convenient if you already return to the event structure when idle. Instead you could check a queue or notifier (just make sure to set a timeout) to get data from the instrument loop.
10-11-2017 08:34 AM
I'd personally stay away from all "one size fit's all" "solutions". All those frameworks solve a few problems, introduce other problems and do not address the real issue**. They're just general architectures that might or might not fit your needs.
I feel a flame war coming on... No need, it's all up to you (the reader not only the OP).
That being said: you do need (some sort of) an architecture, so you might as well pick a template you like. But only if you really like and understand it.
**
The real issue here is how to parse commands, and execute them in a particular order.
I'd make a parent command class, and make each child a particular command. Each command can parse itself if it matches, and a Command Factory method in the parent will simply try all the commands if they match and outputs an array of commands.
The array of commands can then be used in a sequencer class, that simply executes the current command for each station, and rotates them each time all stations commands are done.
Give the sequencer class and\or the command class pause\continue\stop methods\options, and you're 90% there... No need for Dynamic VI's, call and forget\collect, etc.
I'd personally start prototyping this way without any architecture. Just you and the basic building blocks. Then, design and build on that. Eventually a complete application might arise, that will be the simplest solution that does the job.
If not, you'll still have reusable, scalable building blocks (commands class, sequencer class), that will work in any architecture because the solution is decoupled from any architecture.
10-11-2017 04:01 PM
I wonder if a Action Engine would be a good for what he wants to do. I've never had a need to use it, but he does state that "as soon as unit 01 is done with step 1, unit 02 could begin step 1, and so on." If I recall how the architecture works, it could communicate with other steps and let each AE know when the step is finished and keep track of where each unit is at in the process.
Like I said, I have never had to use it and I could be making assumptions on how it works too.
10-11-2017 04:35 PM
I use a JKI State machine like gregoryj. However, I set up my system a bit different.
Here are the advantages in my opinion of this architecture:
Just my 2 cents.
mcduff
10-11-2017 07:25 PM - edited 10-11-2017 07:29 PM
You need more than 1 state machine Period. You need to do more than one thing at a time so, a single loop won't do.
From the brief write-up you will need:
Where the stations send request to remove part and request to receive part There is a natural order of precedence in those states and the private data needs to maintain who is full and who is empty HINT: Station 1-Fail Bin is Pri1 followed by Start-S1,S1-S2, S2-F, S2-P. A correctly written Queue Data type can allow you to preview the queue order by Message Priority (use an enum and sort) and operate on the highest priority move that can be made if any can be made.
Thats the free version- Other versions are available from 8-Ball Consulting