[solved] Pause/delay doesn’t seem to ‘work’

[Anonymous]

I seem to have found a bit of an odd issue.

If I issue the following commands in the firmware:

deltarobot_line(…);
pause(1000);
deltarobot_line(…);

The pause is ‘eaten’. It just goes straight from the first line to the second.

I tried with the pause from the firmware, as well as with arduino’s delay call, neither seemed to actually interrupt at all.

Is there a setting I need to flip before trying to pause and then un-flip, or do I need to come up with some kind of delay myself, or ?

Thanks!

[Anonymous]

is this delta-robot-v3? So, here’s a bit of back story to explain.

In the original code delta robot, stewart platform, arm3, and others were in lock-step: wait for a command, do the command, repeat. This means there’s a hiccup between any two commands (which sucks). So… borrowing from Marlin (3d printer firmware) I moved all the motor stepping commands to the timer1 interrupt. So you set the speed of clock 1 and every “tick” it moves one or more motors.

Well this has a funny side effect – while your motors are moving in the first drawbot_line(), the pause is going on in the loop() call. its like they’re working in separate threads.

I haven’t got working is how to pause – move no motors and let ticks go by.

One option for some people is to add

#define ONE_COMMAND_AT_A_TIME

in configuration.h. This means your commands will work right from the serial line, but the hiccup is back.

Does this help?

PS: Kudos to you for being hardcore enough to mod the firmware.

[Anonymous]

I think I just fixed the dwell problem.

If you’ll recall, the segment buffer is being processed by the timer1 interrupt while the loop() is running in a separate thread (for lack of a better term). I put a call at the start of pause that says “wait until the segment buffer is empty, then pause.” since loop() is waiting for pause() to finish it can’t queue up anything new in the segment buffer, and timer1 is quietly removing segments one at a time until… results.

Let me know if this works for you.

[Anonymous]

That should work.

I was going to look into trying to get the different motors moving on different threads, but now that I’m thinking again, it might not be that great an idea (move 500 steps on one motor, but only three on the other, and 50 on the third — if you do them out of order instead of in small segments, you are likely to not have a smooth line)

And yeah, I am hacking up the firmware because it’s easier than trying to script something to feed in G commands to the serial — and faster

[Anonymous]

Huh. What are you instructing it to do? Maybe there’s a tweak to the gcodesender that we can add to make your life easier.

[Anonymous]

I am currently just doing simple moving/drawing — and rather than code it up in python, I was hacking up the firmware.

It was pointed out to me that it would be better going forward to shift all the nonsense out of the firmware and have python (or something else) interact with the serial channel instead.

I’ve grabbed the most recent source, and it says that current_segment and last_segment are not in the scope for synchronize().

Is there a missing commit?

[Anonymous]

Yikes. Yes! Just committed #11.

[Author]

Posts