# Pulse getting lost in program
**URL:** https://forum.xod.io/t/pulse-getting-lost-in-program/4460
**Category:** XOD Programming Questions
**Created:** [September 24, 2020, 4:15pm UTC](https://forum.xod.io/t/pulse-getting-lost-in-program/4460 "2020-09-24T16:15:57Z")
**Posts on this page:** 13
**Page:** 1
### Author:  [@gweimer](https://forum.xod.io/u/gweimer)
#### Post date: [September 24, 2020, 4:15pm UTC](https://forum.xod.io/t/pulse-getting-lost-in-program/4460/1 "2020-09-24T16:15:57Z")
Is this a bug? Program seems to be dropping pulses.
As you can see from the counters, the pulse gets to the 2nd max-buffer, but never goes beyond that. I would assume programing error, except it is the same node that works in one case, but not in an identical use case.
The max-buffer code simply takes PUSH pulse, defers it, then passes it to DONE, so I don’t see how it could be lost through error or similar issue.
I was having the same issue with 0.34.?, but upgrading to 0.35.2 didn’t help. Same issue in simulation and upload to UNO.
---
### Author:  [@danya](https://forum.xod.io/u/danya)
#### Post date: [September 24, 2020, 5:34pm UTC](https://forum.xod.io/t/pulse-getting-lost-in-program/4460/2 "2020-09-24T17:34:56Z")
Hello. I removed the defer from the max-buffer. It seems to work.
---
### Author:  [@gweimer](https://forum.xod.io/u/gweimer)
#### Post date: [September 24, 2020, 6:42pm UTC](https://forum.xod.io/t/pulse-getting-lost-in-program/4460/3 "2020-09-24T18:42:39Z")
That’s…disconcerting… Besides being just wrong that defer would drop a pulse completely, that “fix” means that DONE will likely pulse before NEW gets updated…
---
### Author:  [@danya](https://forum.xod.io/u/danya)
#### Post date: [September 24, 2020, 6:59pm UTC](https://forum.xod.io/t/pulse-getting-lost-in-program/4460/4 "2020-09-24T18:59:56Z")
The defer is needed in order to create cycles, isn’t it? Why use defer in max buffer at all? There seems to be no feedback, everything goes sequentially and without cycles.
I decided to make logic out of defers. Here’s what it gives me:
Everything works exactly until the third defer. This is really strange.
---
### Author:  [@danya](https://forum.xod.io/u/danya)
#### Post date: [September 24, 2020, 7:04pm UTC](https://forum.xod.io/t/pulse-getting-lost-in-program/4460/5 "2020-09-24T19:04:46Z")
I decided to put the delays between defers, for a very short time. And everything worked.
---
### Author:  [@gweimer](https://forum.xod.io/u/gweimer)
#### Post date: [September 24, 2020, 7:12pm UTC](https://forum.xod.io/t/pulse-getting-lost-in-program/4460/6 "2020-09-24T19:12:29Z")
The current buffer value does loop back to the top of the patch, so defer should be used there. Without a defer before DONE, this results in DONE pulse before MEM is updated, which is not a problem in this example where MEM is just tied to watch node, but would be a problem if DONE triggered an action using MEM value. In this case, the buffer defer could be moved after the from-bus-OUT, but without defer on pulse wire, there is still the chance that DONE will pulse before MEM is updated.
Good thought to narrow the problem down to just pulse passing through 3 defer nodes without all the extra code.
---
### Author:  [@cesars](https://forum.xod.io/u/cesars)
#### Post date: [September 25, 2020, 5:11pm UTC](https://forum.xod.io/t/pulse-getting-lost-in-program/4460/7 "2020-09-25T17:11:55Z")
A bridge from `input` to `output` produces a defer, I pass with the nodes of output-self.
if the implementation is in C ++ …
```auto
emitValue (ctx, getValue (ctx));
```
no delay occurs.
---
### Author:  [@gweimer](https://forum.xod.io/u/gweimer)
#### Post date: [September 25, 2020, 7:33pm UTC](https://forum.xod.io/t/pulse-getting-lost-in-program/4460/8 "2020-09-25T19:33:08Z")
I think you are saying a link from input node to output node in XOD code has an implied defer node, so manually adding defer is not needed. That provides a long-term work-around for my code, but doesn’t fix the problem that a chain of 3 defer nodes will lose a pulse as demonstrated by @danya code above.
---
### Author:  [@cesars](https://forum.xod.io/u/cesars)
#### Post date: [September 25, 2020, 8:55pm UTC](https://forum.xod.io/t/pulse-getting-lost-in-program/4460/9 "2020-09-25T20:55:57Z")
the `defer(pulse)` node has an implementation for error detection, could that be it? I have not tried with previous versions
---
### Author:  [@gweimer](https://forum.xod.io/u/gweimer)
#### Post date: [September 25, 2020, 9:12pm UTC](https://forum.xod.io/t/pulse-getting-lost-in-program/4460/10 "2020-09-25T21:12:13Z")
If there were an error in defer, wouldn’t the node turn red in debug mode?
What could cause an error in defer??? has-error doesn’t seem to work with pulse as input.
---
### Author:  [@cesars](https://forum.xod.io/u/cesars)
#### Post date: [September 25, 2020, 9:58pm UTC](https://forum.xod.io/t/pulse-getting-lost-in-program/4460/11 "2020-09-25T21:58:18Z")
There would not be an error, but when checking if there is an error to pass it to the next node, it happens that the pulse is lost after the 3rd cycle. Is what i believe
---
### Author:  [@evgenykochetkov](https://forum.xod.io/u/evgenykochetkov)
#### Post date: [October 1, 2020, 2:32pm UTC](https://forum.xod.io/t/pulse-getting-lost-in-program/4460/12 "2020-10-01T14:32:03Z")
Hi everyone.
Yes, this is a bug. After looking at the generated code, I discovered that nodes are evaluated in the following order:
The first defer in chain is executed last, and because of that is able to pass a pulse only to the next one.
While I am working on the fix, the temporary solution would be creating a custom node that delays a pulse until the next transaction, something like
```cpp
node {
void evaluate(Context ctx) {
if (isInputDirty(ctx)) {
setTimeout(ctx, 0);
}
if (isTimedOut(ctx)) {
emitValue(ctx, 1);
}
}
}
```
---
### Author:  [@system](https://forum.xod.io/u/system)
#### Post date: [October 31, 2020, 2:32pm UTC](https://forum.xod.io/t/pulse-getting-lost-in-program/4460/13 "2020-10-31T14:32:12Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.