Prevent program to start running after boot/upload

Hey guys

I’ve created my first and pretty decent program for a bag welding machine, worked almost like a charm! But I’ve got an annoying issue though. As soon as I boot the machine or upload a refreshed version of the sketch, the machine/program starts running one full sequence immediately and since it’s doing a lot of relay/welding/stepper action, it’s definately not desirable. I can add a screenshot tomorrow. On top of the sketch are 3 buttons that pulse true when pressed and initiate individual cycles. I’m using the regular 3 pin development push buttons that are wired to 5v . The program ends on defer node, and also using multiple defers in between nodes cause i had to prevent some loop alerts.


1 Like

Your switches go high when pressed, but you are seeing them pulse true on boot? You have a resistor on your digital pins for switches wired to ground to prevent them from floating? I don’t think I’ve every run into this problem. Could it be something lower in your program triggering on boot?

1 Like


I may have found the issue, but haven’t wrapped my head around the issue yet.

My buttons use an internal 10k resistor. When pressed, I get +5v on my signal pin. When not pressed, I measure 10k to ground and 0 voltage.

When I plug the pin into my digital port after measuring, it receives a ´push´signal once and the motor moves. Same when I remove ground connection from my button and re-apply it, without pushing anything.

My button nodes are set ´true´on PRS, but my watch node shows true when not pressed and turn false when I hold down the button ? When I change PRS to false, watch still shows false when pressed but else nothing seems to change ?

I seem to suffer a great brain fart here since beside my startup issue, I had to reverse wire my relays so that they are open circuit when pulled and closed when not active, which I don’t like at all, but even when changing ACT on the relay node, I couldn’t get them to work otherwise.

edit: The corresponding text for the button node shows: ‘Reads a generic button or another mechanical switch. It is expected that the button is low while pressed’

That’s basically not what I want ?

edit2: When I use digital read instead of button, it shows the proper way

Craving for suggestions



1 Like

Right, the “Button” node is looking to got o ground when pressed, and they are digitally pulled up when not pressed. You said that YOUR buttons (I’m assuming you have some physical button) Pulls High when pressed. So, using Digital Read may be better for you. There are safety issues with the electrical, in general, which is why digital signals are split to ground with a resistor, so you don’t burn out your board.

In any case, if your mechanism for bool is the opposite of what you want, you can always attached a “Not” to the output, and get the response you want.

1 Like

The poster above has probably got it correct that your buttons are giving the inverse signal to what is desired and that you’re actually getting pulses on button release rather than button press but I thought I’d add an answer (well quick and dirty hack that should work) to the initial question in case it helps someone else.

First try and find the hardware/software fault causing it and remedy it there if possible. (Just hiding a bug will eventually come back to bite you)

If you still have a problem you could use a gate node on the input pulse and use a timer to enable the gate after a small start-up interval. That will prevent any random start-up pluses from being acted on and once everything has settled and the timer has run out it will continue operate as before

1 Like


Thanks guys. As you suggested, I switched the buttons to digital read, which got me closer to the desired function. I’ll try to implement a gate function and try out if my program stays quiet. I still don’t understand why it still cycles through after every startup, reset or program upload. I can attach the whole file, if you want to peek through it.
Also I switched out my relay cluster to a high trigger, since the previous one has been a low trigger which left me confused as well (just wasn’t aware of it before)

Do I need to have my pins pulled to a specific place beforehand eventually, especially when a low level relay is in use ? Since I’d need a high pin in the very first place to prevent stuff from going bezerk.



Output pins are going to be low on boot. There is no way to get around this. You can set them high early on, but they will never start high. Your code or hardware will have to deal with this (perhaps by leaving nodes disabled until initialization has completed so things like relays are not activated until initialization has completed).

This article may help you…

It talks about the execution order in XOD.
In general, 1) I’ve had some luck controlling execution order by implanting the “UDP” structure into node; essentially forcing it to only execute when a pulse is on an pulse node called “UDP” for update

Example, if not updated (pulse), then return, and don’t do anything… Now, whatever was on the output node will also remain the same when you just return.

if (! isInputDirty<input_UPD>(ctx)) {

You can also then combine with an onboot/flip-flop-gate; and there’s also “wait-all-once”, where you can tie in all the signals from sensors and stuff, before you move on…

and 2) , more powerfully, use of MUX, which gweimer has made an excellent tutorial (note, it builds up to the end, where the real power of MUX was shown)…
The MUX is essential for making complex programs. It could be one of the most powerful feature of XOD.


Thank you! Can’t wait to implement said features, the NOT Node has already done much for me!
Btw, your link doesn’t contain much text or tutorials unfortunately ?

That stuff can be so much fun, when it works :smiley:


The link above is for a XOD library. To actually use it, go to XOD File 》Add Library and add the library to your workspace, then browse to it in the node browser (upper left pane in XOD).

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.