03-16-2015 06:05 AM
Hi,
I'm attemting to take measurements with a DAQ and a Micro Epsilon laser and I was wondering about what archetecture type I should use. The problem is that I have a serial motion controller that I will tell to move a certain distance, when in place I will take a measurement then move to the next positon and so on - I must know that I have taken the measurements at each point. I have created a sample code to demonstrate the take samples section of code that I would use- essentially a for loop for each device and lots of notifiers to ensure that I get the number of measurements I need and that I only take one set of measurements per command.
Is there a better way of doing this or is this the correct way?
Regards,
Joe
Solved! Go to Solution.
03-16-2015 07:32 AM
I would just use a State Machine. You can have a state for each measurment and another state for changing your position. That would combine 3 of your loops and remove a lot of the confusing queue and notifier passing you have going on.
I would still keep a seperate loop for logging. But you only need 1 queue. Make the data type of the queue a cluster with a string and a variant. The string will tell your loop what is being passed to be logged (file name, DAQ data, laser data, stop command) and the variant just holds the data.
03-16-2015 07:48 AM
03-16-2015 08:20 AM
Thanks for the advice,
Reason that I separated them from each other was because I thought it would be complicated if everything was in one loop:
There is a lot of initialising that one sensor requires and also it is fairly slow to read measurements from,
Also, I'd end up putting lots of data into shift registers
And its also useful to be able to poll the sensors/ controller when not doing anything to check their status.
The idea behind the many notifications is to try to create a stae machine between different for loops. Each can be doing their own thing in the background but I know what they are doing when I send a command to them.
Mike, do you have any examples of that structure that I could look at?
03-16-2015 08:51 AM
03-16-2015 11:04 AM
Thanks, I think I've just scratched the surface of your blog - there is some interesting stuff to read on there.
After looking at it I think the best idea would be this:
The main loop a state machine that reads from a queue - as there are a couple of states that need to be repeated for various reasons but are then processed differently ( one repeated case will be DAQ read - there will be an instance once where the output is used to calculate the next motor movement and another will be used to log data)
Another loop for the interface
Possibly a final loop using sephamores to check the status of the connected controller every seccond or so.
Thanks for your help,
Kind Regards,
Joe
03-16-2015 11:36 AM