Absolute Time Pulse Generation

[Kevin_Price]

Back in msg #17 I linked to another thread I made related to this app.  It gets into more gory details, but you may want to take a closer look over there for some more info.

Meanwhile, I tried to do the minimum needed mods to your code that would make it run without error on a *simulated* 6211.

I started by neatening and straightening the wires for several minutes.  I can't claim that doing this pays off in every single instance, but I *will* say the habit of neat straight wires *will* be worth your while in the longer run.

Next, I added an event structure in the loop so that new pulse parameters get written only when they are changed.  You were iterating your loop at the maximum possible speed, doing thousands of redundant and unnecessary writes.  (And if not for the error you *did* get first, you would have been getting a different one due to trying to overwrite pulse params before they were used.  See linked thread for a little more info.)

I got the same error as you.  So I tried updating pulse params by writing to a DAQmx Channel property node instead.  And *that* seemed to work without error on a simulated 6211.

Over in the linked thread is similar code that ran on a real 6341 while using DAQmx Write to update pulse params.  So I'm pretty sure that the DAQmx Write approach would work on your own real 63xx device at work.  But since the property node version should work both places, maybe you should go with that for now.

In reference to the "quirky behavior" I mentioned in my previous msg, the linked thread code worked on real 6341 hardware when I updated only the *Low* pulse param so I think that's the crucial one.  So that's also why I write it to the property node last (multi-field property nodes execute from top to bottom).  You probably don't need to rewrite the constant 2 High Ticks, but I left it there for now to be more sure things would work.

-Kevin P

[James_SS]

Thanks for that and for the explanation- I had not come across event structures too often but can see why this is needed.

I have now tested this and I can also change the parameters on the fly without an errors 😁

I think, like you say, since the property node is definitely supported on both devices, it will be worth sticking to that for when I test this on the engine itself with the 6323 card.

The only potential issue right now is that I am getting a few pulses per revolution from my output- but I believe this might be due to noise from the input of the Z index wire (therefore I am getting multiple triggers per revolution) and I will try and rectify this with a capacitor between this input and the ground terminal. Will let you know how I get on with that but hopefully is an easy fix.

Thanks a lot.

[Kevin_Price]

Whatever you can do to "clean up" the Z index signal will be a good idea.  Once you get on your real 63xx X-series work device, you can look into its digital filtering capabilities.  On M-series devices, you'd need to consume a counter (which you don't have available) to add such a digital filter to your trigger signal.

-Kevin P

[James_SS]

A capacitor seems to have rectified the problem so I am no longer receiving multiple outputs per revolution.

Couple of queries:

I sometimes receive an error when changing the variables, you may have mentioned this already, but I am assuming this because I am sometimes changing variables before rotating the shaft encoder, so the task just hasn't executed before making a further data change? Obviously this won't be a problem when the pulses are coming from an encoder on an engine every few microseconds, but wanted to check that this was the reason.

The other thing is, if I want to write the data in terms of degrees and convert that to ticks (in this case, just need to multiply by 5 before entering the task) (or simply seconds to microseconds) how do I go about doing that within the event structure, as I don't fully understand how that works with the floating variable within the event structure.

For example, I can obviously easily set the initial delay/low ticks at the start to 10 (degrees), then multiply by 5 for 50 ticks, before entering the create channel VI, but how do I ensure that the code knows to always x5 for the updated/new value?

Many Thanks

[James_SS]

Actually never mind- I just realised after sending how straightforward it was to update the new value (although I am still somewhat confused as to how the structure knows what the new value is when it isn't wired to anything)

[Kevin_Price]

RE: error when not yet triggering your pulse generation.  Yeah, this is another quirky behavior.  Once you write pulse params to the task, you aren't allowed to change them before the counter actually generates a full pulse using those params.   In the case of a retriggered pulse, you can't write them until after the 1st pulse ends.  But before your app software can be aware of that fact, the counter hardware will already have queued up that same pair of pulse params again to be used for the 2nd pulse.  At this time, you can write new values, but the 2nd trigger will still use the original params.  Your new params will then take effect on the 3rd trigger.

   That thread I linked a couple times refers to this a bit, but doesn't lay out all the explanation.

When a GUI control fires off a "value changed" event, the value associated with the change is carried along as part of the event and is made available as "New Value".  "New Value" provides the value at the instant of the change, querying the GUI control terminal provides the value at the moment it's queried.

    Why does it matter?  Because it's *possible* (though bad practice) to tie up your event handling loop with long-running code -- then you might rapidly change a GUI control a whole bunch of times and queue up a whole bunch of "value change" events.  Once your long-running code finishes, the event loop will very rapidly work through this queue of "value change" events.   For each one, New Value will correspond to the value at the instant the event was fired and will vary from event to event.  Querying the GUI control terminal would just keep giving you the final value right now over and over again.

-Kevin P

[James_SS]

Yes, I understand what you mean. As I say, I imagine there won't be a problem on the actual engine since the pulses will be coming in faster than I will ever be able to change the value.

For the conversion (and to take into account the fact that the encoder is not indexed at exactly 360 degrees), I'd like to have the control varying every 0.2 CAD- this means converting the DBL floating point control into an unsigned integer (for the value of ticks), so I get the red coercion dot going into the CO Tick task. I didn't think it would be a major problem, but given how sensitive the task required is, I just wanted to double check that there wouldn't be any issues with an additional delay?

Thanks again

[Kevin_Price]

The time to do the coercion will be immeasurably small.  The coercion will round the floating point value to the nearest 32-bit unsigned int, which is almost certainly what you'd be wanting to do anyway, so no need for you to convert to integer explicitly.

You might also consider making the GUI control be an integer and specify Ticks directly.  Then use a "value change" event to calculate the equivalent angle in degrees and update the GUI display to show it.  (Could be a numeric indicator, could be formatted as a string for caption text of the original control...).  Make sure the default displayed values match up in case no one ever makes a value change.

-Kevin P