Stop/Start DAQ-mx acquisition with boolean

[Kevin_Price]

I want to second the advice from ikaiser.  It's a better approach than I described if you have hardware that supports pause triggering on your acquisition task. 

It's possible the software signaling I described could *also* be useful to do things like make new files for each individual actuation, etc.  But the actual coordination and sync between actuation and acquisition will be *much* better if done in hardware.

-Kevin P

[Simon-lee]

Hi ikaiser,

Can I apologise for my tardy reply, I’ve been stuck on an export control training course all day and I’m convinced my brain has shut down in self-defence.

Hardware wise I’m using

NI-cDAQ-9184 - 4 slot chassis

NI-9375 – digital lines

NI-9481 –-Relays

NI-9215 – voltage (attached to a current shunt)

NI-9211 - K type thermocouple

I’ve only managed a quick scan of your attached link but if I understand your advice then I can use the NI-9375 as a digital source to trigger the acquisition (or perhaps there is a way to use the relays but they are energised at 28 volts and the motors generate some heavy voltage spikes).

But I do like the idea and Kevin also recommends it so all I need try and understand how to implement it.

I will do some background reading but if anyone fancies knocking up an example I would be very interested.

Regards

[Simon-lee]

Hi mcduff,

I had a play with your project (thanks for that) and you touched upon a DAQMX event to drive the event structure. I’ve never come across a DAQ-MX event before and NI didn’t cover it in their training, it looks like a genius solution.

Are there any drawbacks because I can’t find many examples?

Can you flesh it out at all?

Regards

[mcduff]

I wonder if we work in the same place, as I also have to do export control training. You know that software/code can also count as a prohibited item?

So as stated earlier hardware solutions are always best. I am just guessing here, so correct me where I am wrong:

1. Your timing requirements are not strict, that is, with hardware you can start an acquisition within microseconds or less, but for your case, if we start within a few milliseconds, it is probably okay.
2. Did the event work in the project I sent?

If your requirements are not too strict, I would keep it all in a single loop by using more events naturally.

1. At the start I would initialize your 9215 and set up it to acquire continuously, and send an event every N samples.
2. When the DIO event occurs I would then start your 9215.
3. Your 9215 will generate an event every N samples it acquires, depending on how you choose N and your sampling rate will dictate you event generation. Myself, I would not go smaller than 100ms.
4. Once the parameters in 3 are chosen your 9215 will generate an event every N samples after you start, you can then display, store the data etc. For example, assume my sampling rate is 1000Sa/s and I set my event for every 200 samples. Every 200ms I will have an event with 200 samples in it.
5. When your final DIO event occurs, send a stop to the 9215.

This is all contained within one loop which is easier to debug. If I have some time this afternoon, I will try to add in support for the 9215 in the example I sent.

I like the events because you can naturally add UI interactions. In (4) above we have a 200 ms delay before a N sample event occurs, this allows me to have a stop button event that will stop the acquisition in the same loop, without doing anything extra.

In the example finder, there is a Voltage (with Events) - Continuous Input.vi (This is how I would set up your 9215)

mcduff

[Simon-lee]

Hi mcduff,

I had the export code thing drummed into me this afternoon, where a sub vi becomes code wasn’t answered and they get pretty paranoid about almost everything.

If you have D4G4 and compliance training it must just be the same organisation.

I’ve played with your sketch at home but training kept me out of the lab, the plan is to get in early tomorrow and hook it up to the genuine hardware.

Your assumption with regards to timing is correct, it’s a sluggish electro-mechanical actuator so accurate timing isn’t possible or required. I was planning on monitoring the extend/retract time, if it takes to long, I will cut the power and sound an alarm to prevent further damage.  

I will keep you in the loop

Regards

[mcduff · Accepted solution]

Attached is a quick mock-up, ie buggy, code of what you can do.

You need to add states to it for saving data, etc along with other things.

You may get an error if your clear the task before unregistering the event, don't remember. So you may have to stop the task, unregister, then clear the task.

Good luck.

mcduff

[JÞB]

Now that I can actually see code... I would say the largest trouble is using a queue! we are trying to react to state and I think a notifier would be more responsive.

[Simon-lee]

Hi mcduff,

That's a seriously impressive piece of work. (after I managed to get it past works firewall) thanks for all your hard work, its really appreciated.

I've just started trying to get my head around the logic but these a lot of new concepts so it will take time.
One initial question:
I'm getting an Error -200523 at main vi
(Possible reason(s):
Read cannot be performed because this version on DAQmx Read only returns data from a single channel, and there are multiple channels in the task.
Use the multichannel version of DAQmx read.

I've chased the Digital: InitilazizeRead frame which looks good (by my standards)
I'm now looking at the Digital: ReadState DAQmx read (U8 1 chan 1 samp) but if I change to a Nchan 1samp i get a broken wire 
What I don't want to do is hack at the vi without understanding it, can you point me in the right direction.

Regards

[mcduff]

Make a back up copy if you are worried. But I put something together really fast and it could be improved alot, make subVIs, a type-def, better error handling, etc. You should experiment and make it your own.

About your questions

---

@Simon-lee wrote:

Hi mcduff,

That's a seriously impressive piece of work. (after I managed to get it past works firewall) thanks for all your hard work, its really appreciated.

I've just started trying to get my head around the logic but these a lot of new concepts so it will take time.
One initial question:
I'm getting an Error -200523 at main vi
(Possible reason(s):
Read cannot be performed because this version on DAQmx Read only returns data from a single channel, and there are multiple channels in the task.
Use the multichannel version of DAQmx read.

I've chased the Digital: InitilazizeRead frame which looks good (by my standards)
I'm now looking at the Digital: ReadState DAQmx read (U8 1 chan 1 samp) but if I change to a Nchan 1samp i get a broken wire 
What I don't want to do is hack at the vi without understanding it, can you point me in the right direction.

Regards

You can change it like so, you will need to change the event case also, so change Digital: GetReadState, and the Event Structure case since there are multiple channels. Sorry I missed that.

Use the boolean array to number primitive. You will need to check the order of the boolean array to make sure it corresponds to your channels. You can also decide to get rid of Digital Read Number and just stick with an array, probably easier in that case.

mcduff

---

---

@Simon-lee

[Simon-lee]

Hi Jeff,

I’ve taken on board the notifier suggestion put forward by yourself and Kevin, I went with the queue because one limit switch only works as an impulse switch and I worried a notifier might miss the event. I’ve now tested it and it works just fine.

While I can see that mcduff’s solution is elegant and professional. I also know I have a steep learning curve before I’m on that level. Having a fleshed out project is a goldmine and massively more informative than single line examples.

One of my problems is I work in an environment where Labview is unknown, I convinced the management to spend a sizable sum on licences plus Core 1 & 2 training but combining training and examples into a full working projects is proving tricky without advice.

To that end, while I will probably use a version of mcduff’s vi in the workshop, I'm determined to build one based upon my core 1 & 2 training. I feel that’s the best way to improve my skills.

I will post my finished code, which will, with luck, generate humour and horror in equal measure.   

Thanks and regards