I have given this a go in the attached file. I know in the previous thread you used some event structures to be able to change the parameters on the fly...any suggestions on how to go about doing this in this case? You said that the starting time would only be relevant for the first pulse, so wondered if that would cause issues with the ability to change the sampling time during a run?
The code you posted needed several mods. I highlighted all the things I added or changed on the block diagram in cyan. Most importantly, I added the necessary calls to configure a trigger and to set up continuous sampling (to generate a continuous pulse train instead of just 1). Be sure to compare it to your original, note the differences, and try to understand why I made changes.
This example does not attempt to demonstrate anything about changing pulse parameters on the fly. Apparently I did that in the other thread already so you should just follow the idea that was already shown there.
Thanks a lot for this. I'm very sorry as I thought I understood that the use of high ticks and low ticks was essentially a way of simulating the trigger in that when the signal is 'high'/triggered the signal would send the 5V to the output terminal I specified. I am therefore not sure what the 'trigger' source is meant to be as I had assumed it was my settings that were dictating the trigger. Or is this set to the same as the output terminal and it is implicitly driven i.e. your trigger source should be the same as when you're outputting the high ticks? (As you can probably tell I am trying to understand this as I type so apologies if I'm not making any sense).
We are talking about two different things.
I'm using the word "trigger" the way DAQmx uses it. A digital start trigger is a digital *input* signal whose active edge will let the task start running. For you, that should come from a once-per-cycle sensor like TDC or similar. Upon receipt of the designated active edge, the counter task will count out 'Initial Delay' worth of encoder cycles, then repeatedly cycle between transitioning high for 'High Ticks' worth of encoder cycles and then transitioning low for 'Low Ticks' worth of encoder cycles.
I think you're using the word "trigger" to describe how the counter pulse train *output* will drive the valve. That's going to lead to confusion IMO. What you're sending out to operate the valve should be thought of as a "control" signal because it directly controls the open/closed state of the valve.
It's maybe a subtle thing about the terminology, but sometimes the details matter for clarity.
Oh I see. Yes, I'd say some of the terminology can be a bit confusing as words that are essentially synonyms can actually mean completely different things- but something I should get used to. You're right though in that I was thinking the 'trigger' referred to the thing that triggers the valve. I sometimes find the flow of these channels a little confusing- the Z index is called 'after' (at least sequentially next to) the overall output. In my head I'd think all inputs need to be clarified before setting the output terminal.
I have modified your code to include the changes made previously to the injection code that enables values to be changed on the fly. I still have 4 different case structures but I wondered if I only need 3 now given that we are now only modifying the inputs of one task now (as opposed to the 2 counter tasks before). So right now I have 2 different cases for modifying the sampling duration (high ticks) and the sampling offset (initial delay), but guessing I can do this in the same structure?
I had a look back through the previous thread where you talked about the case structures being used when the values were changed. I tried to carry over that as best I could and modify as little as possible to theoretically get the same outcome here. For now I am still only able to send the signal by their default timings- both delay time and high ticks.
I thought I remembered beforehand that you mentioned you are not able to change the initial delay value on the fly, but when looking I can only see that you mention that the low ticks are the important ones because the delay only matters for the first cycle. Since we are now not using low ticks as we were with the injector, I presume this would be difficult? Could I use a retrigger and enable delay on retrigger or would that undermine the point of using a continuous pulse train?
The other option you mentioned before was using the DAQmx write:
High time (or high ticks) *can* be changed during the run, but it'll probably be best to call DAQmx Write rather than using the property node. There's a quirky behavior where it matters which one of the two pulse timing parameters is written to the property node. One of them takes effect right away, the other seems to get ignored (unless you later write to the first one at which point both take effect).
Instead of trying to remember which parameter "matters" in each case (freq/duty, high/low time, high/low ticks), it's easier to use DAQmx Write where both are required and will both take effect right away. (You don't have to *change* both values for things to take effect, you just have to write to them even if one of the values is always the same.)
I don't imagine it's a cause for this particular issue with changing things during a run, but I imagine I would have to wire in the low ticks to the property node too given that both low and high ticks need to equal 3600.
To be honest, the timing itself is less of an issue to control on the fly, but I would need to change the duration to the point of being able to at least turn the valve off and on when needed, even if the pulse needs to be sent the same time during an individual run.
That "quirky" behavior you quoted me on makes it necessary to write to the Low Ticks property to make settings go into effect (see msg #31 over in that other linked thread). Writing only to the High Ticks property as you do in the latest code won't be enough.
Attached are the slight additional changes that ought to let you change pulse duration on the fly, though the pulse will always start at the same offset angle.
Ok thanks a lot that's all making sense now. Will try the code out next Tuesday. I think it will be fine for me to predetermine the timings I need and then use the duration to turn it off and on during a run. When I tried it yesterday, like you mention in the code, it threw up an error when I tried to change the delay period, but not the high ticks (even though changing the latter didn't change/write anything as you refer to), so I will just delete that event structure.
Hope you are well. Apologies for the additional query, but my colleague is trying to achieve a similar control system as the one used for my injector, except he is also trying to control spark timing and a camera. I gave him the code that you made so that it should just be a case of swapping counter numbers and ports, but there seems to be issues. I wasn't sure how possible it was to run 3 separate outputs on the same card, even if you are using the same shaft encoder signal as your first counter (it looks as though inputs and outputs start to interfere with each other if you try using all counters available on the card simultaneously).
As a result, he has reverted back to the code that I was initially using that could only control the pulse output on a crank angle degrees basis, not absolute time, but even then I think there are problems with generating the signal. I have attached his post below, if you have any advice on things to try to help with his issues that would be great. Unfortunately, I can't be in the labs to help in person, so I don't know if this is in fact a problem with the code or something hardware related.