Need help finding quirk in flow control program, Arduino seems to reset

[djetschin]

Hi XOD´ers,

Happy new year everyone. Last year I’ve started to build and program another automation tool, basically with one stepper, 3 Festo solenoids and endstops on 3 axis. I THOUGHT that’s gonna be a breeze, not so much. I got it working quite okay, but one issue that pops up most of the time, but not EVERY time, which has me confused if it’s in the program or hardware related.

Therefore over the holidays I’ve educated myself on proper flow chart programming on sps systems and rebuild my whole program mostly from ground up. It ran a little better but the issue still persists.
I even optimized the hardware setup a little and tried some stuff, like another supply for the arduino alone if it may have been power surge. But no change.

I’ve attached the file, unfortunately I don’t have the old one on this machine, I’ll add it later on if you wanna check.

What it should do: (for now)
-´home´ stepper (that’s the best layout I’ve been able to come up with) If not already
-Sensor or button triggers
-motor moves arm out X steps and should equally hit endstop for safety ( originally with infinite steps until hits endstop, but it overshot at certain speeds which would prevent further operation)
-pneumatic axis forward
-gripper
-pneumatic axis back (after X sec cause gripper not confimed)
-motor moves arm X steps back
-pneumatic tilt axis forward
-gripper open (after X sec)
-pneumatic tilt axis back
-motor back to start pos

Repeat

Every action uses it’s transition requirements and only moves on when met. Didn’t include an alignment impulse yet but I as well may.

Everything is fun and games until it comes to the last step, motor back to start.

-It either does nothing (and the debug mode freezes and doesn’t show live endstop motions anymore, but FYI the tilted back sensor freezes on ´false´ when it should be true for the next step obviously.
-sometimes it does what it’s supposed to
-oddly, it seemingly does what it’s meant to (that’s a hard one to figure out first) but not quite. It moves back home, but it’s the initial home action, and not the last steps return action. figured that one out because the first home move uses slower speed than the last return one.

So it seems to kind of either freeze or reset itself at that point. When all it has to do is literally pulse on true into the stepper node.

I’m using original Arduino Uno, 8 channel relay low trigger, 24v ps, 5v stepdown supply, Lichuan stepper driver, nema 17, 3,9k pulldowns on every endstop (10k at first, gave the 4k a shot to rule that out)

what just came to mind, the pneumatic endstops are 5-30v but I run them on 5 because lazy (haven’t wrapped my head around voltage dividers quite fully ), that may be an issue ?

The wires are not that short though, 800 mm from unit to controlbox. motor and sensors are separate cables.

Let me hear your thoughts and critics,

thanks, Daniel

Picker_22.xodball (83.3 KB)

[gweimer]

Very unique use of jumper to tidy up the code. I suggest looking into to-bus & from-bus to make it even cleaner. It can also help with the 1st thing I noticed: There are multiple copies of nodes reading the same input pin. While technically this should be OK for digital input, it could be causing unexpected behavior. Using bus nodes, you can use the output value from one node from multiple places in your program without having wires crossing everywhere:

You can pick better bus names, but this gives you the idea. Bus nodes could also eliminate your need for so many jumper nodes and long wire runs and branches. Careful naming of bus nodes adds documentation of what the wire actually represents.

There also seem to be quite a few unused nodes that have a chance to cause unexpected interactions (defer and pulse-on-true nodes that don’t link to anything).

Taking notes as I try to understand your program…

1. On boot, you retract the arm until limit switch is on (skip this step if switch already on)
2. If arm is retracted and startsignal (I assume button is pushed), Extend the arm (here you assume the extend switch will be triggered after specified steps; nothing stops the motor if switch triggers early and program hangs if switch doesn’t get triggered)
3. If successful so far, turn off relay for X-driving (not sure what this means…)
4. Code layout implies turning off relay will move X in front (switch for X-behind has been true until now).
5. After 0.5 second delay, you turn off picker relay and delay another 0.2 seconds.
6. Once that has all completed & X is behind & arm still extended, retract the arm (to mid-point, not start position)
7. When retract completes, turn off pan relay and wait 1 second
8. Turn the picker relay back on
9. Wait 0.5 seconds and turn pan relay back on
10. Move the arm back to start position. This moves a set distance and assumes the home switch will get triggered.

I don’t see how the original “move home” block can be executing again at the end. It only fires on boot signal (and only if arm is not already home). The 600 PPS in last step is slower that the 1000 PPS moving to treadmill. Maybe you are just assuming it is only 400 PPS?

As mentioned above, you have multiple copies of the switch nodes. You also have multiple copies of stepper node controlling the same stepper motor. This SHOULD be OK since only one should be active at any one time. When possible, I prefer to have only one node for one device and change the input values as needed. In this case, you already have a pulse to start the node, so you could use a ‘select’ node to select input values.

I’m not seeing anything obviously wrong with your code, but I’ll take a look at how you might clean it up a little. Using only one stepper node with select values could look something like this:

You can repeat to change PPS values for each pulse (just duplicate select node and have each pulse link to both select nodes). You can probably come up with better bus names. Here I used M to Move to location and Is for switch indicating we are at location.

You did use only one relay node for each of your relays, and you are correct to use flip-flop to remember state that relay is supposed to be in. It seems like you have more flip-flops than you need, but I see why you did it to remember the state you are currently in.

You could replace the “I am here” flip-flops with a counter to remember which step you are at (which would eliminate the need to reset flip-flops later on), but it adds a bunch of compare nodes to figure out which step you are at and makes adding a step to the middle more complicated, so it is more of a preference than one idea is better than the other. Here is just the 1st couple states to give an idea what it would look like:

The any/defer/count is tracking what State we are in. I put defer between any and count because most of the inputs to any will be looping back up the program; this removes need to put defer on each one.
The select/Arm nodes are moving the Arm to the requested position. On boot, State will equal 0. We could check for that, but there is no reason to. Each time the Arm finishes moving, we advance to the next state.
The top-right is an example of relay control of X & same can be used for gripper. If there are multiple ways to set/release either one, you can add an any node above flip-flop.
Below the any/count nodes are example of code for State=1 (extend arm) and State=2 (turn off X relay)

While describing this, I noticed a bug. If arm is already at home position on boot, we never advance to State=1. The easiest way to fix this is probably add a 2nd gate below boot. If IsHome is True, allow boot to pulse any node to advance to next state.

Again…this is not necessarily better than your solution, just a very different way to look at it. Debugging this version might be more difficult than your version.

Sorry I couldn’t just find the problem in your program. It MIGHT just be duplication of nodes for single device, but that doesn’t seem real likely if it only affects the last move. It could be that a positional sensor isn’t getting triggered like you expect, but returning to home/base position seems like the most likely place for that to happen, and that happens after you move in the home direction.

[djetschin]

Good day!

First of all, thanks for that extensive reply! I’ll try my best to reply accordingly and detailed!

I knew that you’d comment on my jumper nodes, lol! I stole that idea from your traffic light tutorial to be honest, and yes the upside down issue made it looking sketchy !

I also attached my first design of the code, which was all over the place imo. As a newbie, I had yet to make the right choice of what to use as a control impulse; boolean or just pulse. I was afraid that a pulse will get lost somewhere, a boolean instead is either true, or not. So to be safe I went with the boolean idea as best as I could.

The floating nodes, they used to be connected somewhere, but for testing I removed the buses but left the nodes to not forget they were once there until I made sure I can get rid of them.

My ultimate goal is to have anything as clean and minimal as possible. But as I’m still new and figuring, it seems that 10 ways lead to rome ultimately but I haven’t come across the most obvious of them.
When cleaning out those wires, I’m yet afraid of getting lost in the mess I made, haha. When I get back to it after some days out, I’m already like, lost at first until I’ve done some tracing.

But as you suggested it’s definately better to use each node just once and bus them, I actually really just wanted to avoid wires spreading like a web. But I understand the issue of it causing future problems.

One day I messed around with some simple add/subtract nodery on my stepper PPS and when tweaking the number by clicking manually, it’s been a nice RPM control while steps were set to INF. But I failed miserably while trying to replicate that in an automated fashion by using delays or timers.

Since I was planning building some sort of smooth start. Because the set values for now shall be ramped up significantly down the road, it works up to ~1800 but not higher, then it sits there spinning (magnetic) wheels so to speak because it kicks in to rapid.

BTW. does the node ever output a done pulse when running on INF ? I guess not so, maybe when then reset?

The optimal route to go would definately be using an closed loop stepper and ditch the forward endstop. It just exists to make sure it actually went there. Which it probably most of the time always will. But you’ll never know with those sneaky nema 17 rats! And it shall remove stuff from moulds in a safe and timed manner every time, or crash! But ultimately the position needs to be tweakable via menu, which would imply you move the endstop trigger by hand accordingly every time. Not very 2022!

What’s also planned is the addition of an LCD with some menu choices and a twist/push button. A clean program layout definately helps with that!

You seemed to have catched the intended principles of my unit quite well, actually the relays are off when everythings idling and turn on when they come to use. Hence the ´not´ nodes for the lowtrigger.

Today I’ve tried a seperate 5v supply for the endstops, my DI pins receive a solid ~ 4,7 v most of the time when triggered, so that should be good enough as a definitive high impulse. No improvement though
As you’ve noticed, theres no way the home impulse gets triggered in consequence of program flow.
It could only happen in a reset state of the whole unit. Which somehow seems to happen as there are no other obvious issues that meet our eyes…

I’m sure that it’s the home impulse though, BECAUSE the last action uses x steps. While testing I swapped out the driver module which only allows microsteps this time so my set number of steps needs to be doubled to have it reach it’s positions, right now it only does half of it. BUT since the home sequence uses ´move until endstop´ rules, and the last step right now seemingly hits home again with no issues, it can only be that. otherwise it’d stop just halfway there as well.

I’m gonna rebuild the whole shenanigans this weekend and hit you back up with my latest creation and gained knowledge, haha.

I also feel the need to automate every corner of my house now lately, just because I guess I can lol!
But I really need to get a hand on some screw terminals for the arduino board. Pinning stuff to it in a professional way is otherwise impossible. Also that control box is just somewhat winged and ´needs to work first´-messy. So little space, I already dumped the power supply into a seperate box.

Thanks for the suggestions and the effort!

Picker_21.xodball (56.4 KB)

[gweimer]

The help for the stepper node indicates DONE fires when all N steps have completed. This would imply that it does NOT fire if RST is used to stop movement. You could use an any node to join the DONE output and RST input so you always know when movement has stopped.

It will be interesting to see if your problem goes away when you get rid of the node duplication…

[djetschin]

Good Day!

Picker_Gweimer.xodball (101.1 KB)

I’ve attached the newest file version. It’s definately a lot cleaner, maybe some defers over the top but it gave me loop warnings so I’ve tried my best.

• when I cycle every step through by hand, it seemingly works.
• when the motor comes into play, same issue as before. Fun levels are descending.

It either resets or freezes. I might just ditch that uno for a mega and try again.

I’ve attached videos of the misery you can watch them

here Xod Pick issue - YouTube

and

here Xod Pick issue 2 - YouTube

Thanks

[gweimer]

If I’m seeing things correctly, DoPickOpn flashes true just before everything stops. This implies you made it to Pick auf (7) (made DoPickOpn true), and Schwenk zurück (8) (triggered RST6 to make DoPickOpn false again).

False assumption: The next step needs HomArm to be true to fire, so either XHome or CHome is probably false when you are expecting it to be true.

Reality?: DoCBck should be true the same time DoPickOpn gets set back to false (RST6 triggered). We don’t see DoCBck go true, so that ?probably? means it is switching back to false very quickly, which is triggered by RST8 (Arm auf Start (9) going true). Again, we don’t see DoArmHome true, so it must be getting reset by RST9, which means ArmHome is getting triggered. You could test this theory by connecting a count node to the flip-flop-MEM pins and put a watch node on each count output. It won’t help your program, but it might help with debugging to see how far down the chain your pulses are going without missing any quick “true” pulses that watch node might not see. If any of the counts on a flip-flop remain at zero, you at least know where the program is stopping.

One possible hardware bug might be that motor or relay is drawing enough power that you are getting false-triggers on your sensors that generate an extra pulse in your code. Sometimes this can even cause the Arduino to reset. I don’t see any evidence yet that this is a problem (except that you mentioned the arm sometimes returned home at the initialization speed, which could indicate a board reset). Seeing the count for each flip-flop after a single run should help narrow things down.

[djetschin]

Hi,

Okay. So, today I’ve tried to add the counters per your suggestion (great one btw) and THEN, I was notified that I exceeded my memory space, which was 103%. So that thing’s already maxed out, no wonders why it goes nuts I guess. I tried adding the last 4 counters, which worked and showed 1 for every flipflop.

Afterwards I removed everything, tried it again, one time it worked, next time it acted up … So I guess I reached the RAM and memory limits already. I’ll try the Mega next and see what happens. On my bigger project I’m also using the Mega with no issues and the program looks way messier than what you first witnessed.

I’ll be back

Dan

[djetschin]

Hey,

It’s finally running!

Pick unit works

Swapped out the uno for a mega, found another small quirk after being able to now properly debug, and it went well for hundreds of cycles as I was just casually having it chugging along.

Btw. is that accelstepper node now working ? I’m still looking for something that provides me with such feature

Thanks a lot for all the support so far, hope I can contribute back in the time coming

Dan