Execution order confusion

Hi All,
I am trying to create a node that will take a series of input numbers, add them all up and subtract the result from a fixed number.

The intention is to generate a PPM (pulse position modulation) signal for use in radio control of a vehicle. To do that the transmitter sends a “frame”, which is a stream of varying length pulses (with each pulse representing a servo position) with a sync pulse at the end. The frame length is fixed length, usually 22ms. The sync pulse must be 22000 minus the sum of the widths of all the channel pulses, which are between 1000ms and 2000ms. The sync pulse will always be much longer than the longest channel pulse, so the receiver can detect it and then know that the next pulse is channel 1.

The node I’m trying to create is just to calculate the length of the sync pulse. But I am getting strange results, and I can only guess it is related to nodes being evaluated in a sequence other than what I am expecting. For testing, and to make the arithmetic a bit easier, I’ve set the fixed value at 200, and I have eight pulses with lengths varying from 10 to 17. With these values I would expect the result to be 92 (100 - 10 - 11 - … -17) but that is not what I get. I actually get 85. The intermediate results are different too, as they seem to one less than the number I’ve actually subtracted.

I don’t know how to correct this. Or would it be easier to just do it in C++?
Thanks, Ian

Something is not right there, because in the first run the results are negative.
Then if they are positive with those results.

where does 100 come from?

Hi @cesars, Sorry, typo, It should be 200 of course, which comes from the if-else node (hard coded on the “T” pin). I haven’t been able to figure out how to initialise the value before the first loop, so the first time through the values are subtracted from zero. From the second iteration the value is set to 200 before anything is subtracted from it. It doesn’t really matter because the first iteration will be long gone before my finger is off the on switch.


The problem is buffer is only initialized to 200 at the END of each run. It starts as zero the 1st run and gets numbers subtracted from it.

A better way to run this loop would be to move the if-else for initial value to the left pin of subtract. if count=0, then subtract from 200, else subtract from buffer.

Even more importantly, why is it being done as a loop? You are trying to calculate the length of the 1st pulse based of length of later pulses, so you will need to have (and remember) all those pulses, so why not just subtract them all at once? Since you don’t want the pulse-values changing, I would recommend using buffers to store the pulse lengths while you are processing them.

Sample using just 3 pulses (easy to expand for all your pulses).

Hi @gweimer, thanks for the reponse and a solution. The first loop going negative didn’t really bother me as it would be updated 22ms later and would be fine from then on.
My concept is that the values for the pulse widths are read from analog and digital reads. As each read occurs it updates the value in the buffer related to that particular input. At the same time, and probably asynchronously, the buffer is read and the sync pulse calculated. Then the whole frame of servo control pulses plus sync pulse is sent to the RF module to be transmitted to the receiver.
The reason I tried to put the processing in a loop is because, as far as I am aware, that is standard practice for imperative languages, i.e. the sum would be done in a “for” loop. So my first thought was to do it the same way in xod. Translating your solution to a more standard language, it seems to me, would be something like

result = buffer[0] + buffer[1] + buffer[2] + ... + buffer [7];

Nothing wrong with that in this case, but could get a bit unwieldy if the list contained many values. I just feel that a loop is cleaner and tidier than adding lots of buffers. Maybe I’m trying to overlay my imperative style thinking onto a language that it doesn’t really fit well with. Don’t know, I’m still learning.

I do like the simplicity of your solution though. Thanks for that!