Movement randomly starts/stops during moves in STEP/DIR mode

adam · 2016-04-03 22:20:46

Hi Shahin,

by your suggestions i have switched to step/dir mode, without any external programming. my stepper driver (still trinamic board) also has step/dir input which i have connected. however, when I move the motor useing NanoDLP Calibration interface, the movement looks pretty weird. I have made a video to show you, so it's easier to understand.

I was Moving 10mm up but movement was not consistent.

http://sendvid.com/f9wirmer

- to see if it's a problem with my controller i have connected step pin to an LED instead of the controller and it's the same behaviour (LED is off roughly in the same pattern as seen in the video).
- I have also tried two different Step pins on the PI (BCM 17, BCM 24).
- third thing i tried was reducing the microstep res to 8 (64 is the controller resolution), same problem.

have you seen anything like that before?

Shahin · 2016-04-03 23:01:10

Adam,

Actually I think you had prepared pretty good workflow/code for Trinamics. If you could translate same codes to gcodes alone without any syscall dependency, I believe you could achieve better result.

No I have not experienced such movements. And I am using step/dir mode exclusively. How many pulses do it sends per second? Decrease number to see if it improves things.
http://www.nanodlp.com/MOV_0025.m4v
Unfortunately I do not have better video, it belong to a year ago, comparison of our python backend with new go backend on RPi 1. Both were working but go version was working much better. And things improved a lot including transition to RPi2 and better GC and OS optimizations.

nanoDLP do acceleration and deceleration for step/dir but I think z-axis movement on peak speed totally stalled. Also slow pulses in the beginning just make sounds instead of doing any movement.
Do you have any simple driver around like DRV8825? Maybe it is somekind of trinamic optimizations which gone wrong as our os based pulses are not perfectly shaped.

adam · 2016-04-04 19:20:34

I believe this has nothing to do with the trinamic driver, because when i connect the LED instead of the driver, i see the same irregularities.
Furthermore, as i've checked now, no steps are lost. 10mm gives me exactly 10mm of movement despite the irregularities.
Is it normal to have a variance of almost one second between movements of only 8400 pulses?

unfortunately i can't translate my code to GCODE because of the packet format and checksum calculation.

I will keep on trying with different settings.

Shahin · 2016-04-04 19:33:37

Adam edit your z-axis height. Maybe there a bug with negative z-axis value.
What value do you use as max/min/startup speed on the setup page?

Pulse sizes depends on your speed values.

Did you send binary commands to trinamics from your python script or you return values to nanodlp and send back the result to trinamics through nanodlp?

adam · 2016-04-04 19:58:05

I have used the result from python in NanoDLP.
My current endeavour is not about instability with Trinamics though. The way it worked before was pretty good. I'm just trying whether the NanoDLP functionality will be enough for me to reduce complexity in the system.

The cause for the stepping error might be as you assumed. The step frequency is probably too high.

the screenshot is what i've tried now and it seems to work OK. My driver has 64 microsteps and 400 steps/rev though, so it might be too much to handle (43k steps/sec at 5mm/sec). Have you done any experiments as to max frequency?

The CPU shows 300+ % while moving...

adam · 2016-04-04 20:02:02

this is what i found, up to 22mhz with native C, what kind of approach does GO use?

http://codeandlife.com/2012/07/03/bench … pio-speed/

Shahin · 2016-04-04 20:35:43

Approach is same as native c library. But it would not be even close to C level performance. At-least I can say it has couple of times higher performance than python libraries.
On SLC/SVG upload, performance takes hit even though it always keep a core idle. If you find it useful I can do testing with oscilloscope.

Good news is that with every new go release (every 6months), we get pretty nice performance improvement in program. I hope trend continues.

adam · 2016-04-04 20:44:58

If you could test the frequency it would be really helpful. I could try a setup with a sound card, that's the closest i have to an oscilloscope but it has max 96khz samplerate so it won't be of much use..
Maybe that's something where the RPi 3 could come in handy. Finally a reason to buy it.

Which speed is used for reference search?

adam · 2016-04-04 21:15:37

I have done some quick manual tests. at around 1000 steps/sec it works fine, at 4000 the stutters are noticeable, trying more than that (25k+) i get connection timeouts in the interface from time to time, while the motor is not moving.
So most definitely the step generation is the culprit. I don't get why it's so bad though. What is the usual settings you run with?

for the near future i will switch back to trinamic internal step control, which has the additional benefit of almost noiseless operation, while any other GCODE controller i've seen so far produces lots of whistling.

Last edited by adam (2016-04-04 21:20:46)

Shahin · 2016-04-04 21:46:12

I believe it is normal. We need to do couple of things in addition to sending perfectly square pulses in contrast to pure pulse generation benchmarks.

Checking Limit
Checking emergency stop / Interruption from other commands
Calculating square root for acceleration
Counting steps and etc
As it takes time to do above steps. You need to keep time too! as you need to calculate correct sleep time for better movement

We had better one which used to cache acceleration and other calculation. Does it worth for dlp printers? I do not think so as we would not need to move fast during print.
Also there are other issues are involved in which are much harder to solve such go gc, linux scheduler.

Actually it is possible to generate perfect pulses with very high speed through DMA but it requires much more effort and low level hardware/os knowledge. Acceleration will be really hard to do any fault detection, emergency stop, limit detection will be much harder to do in realtime.

I use default setup settings.

adam · 2016-04-04 22:04:14

Thanks for the extensive answer. You are right, for DLP printers currently the focus should not be too much on motor movement. ( if you think of carbon 3D and continuous motion, that might change in the future though).

You know that i really appreciate all the hard work that goes into this piece of software. Without it, my printer would only be half as good
Keep going!

Shahin · 2016-04-04 22:30:10

Your suggestions and contributions during past couple of months helped this project lot, thank you.

Due to communication delay between rpi and arduino. I believe direct control will be more suitable for continuous motion. I know it generate strange sounds but I have not seen any missing steps in my measurements. So it safe to increase speed a little bit as we do in our current setup. 3mm/s will be more than enough for any dlp printer tech available.

We are trying to use both direct control and RAMPS board for movement in another project by choosing between RAMPS and step/dir pulsing dynamically. It is complex but perfect alternative to our current setup.

I do have plan to use trinamics in my next project their stall detection could be really useful, hopefully you keep using them.

Shahin · 2016-04-05 15:59:58

As per requested.
Default setup setting

Twice speed

I could not go higher because pulsing gone crazy.

adam · 2016-04-05 20:11:48

Yeah, 2+ KHz, consistent with my experiments. Thanks very much for confirmation.

Cheers^^

adam · 2016-04-05 20:13:20

what kind of oscilloscope are you using? do you know any good, cheap USB ones?

Shahin · 2016-04-05 20:42:06

I do not have much knowledge in electronic to compare models but based on what our electronic guy told me.

He is not happy about USB unit (not very cheap). I do not remember model but I can send details tomorrow. It was pretty useful for parallel recording for special cases not general use.
Above screenshot is from GPS branded standalone unit with USB and he is happy with it.

It looks like this unit in this photo. Again I can send details tomorrow.

nanoDLP

#1 2016-04-03 22:20:46

Movement randomly starts/stops during moves in STEP/DIR mode

#2 2016-04-03 23:01:10

Re: Movement randomly starts/stops during moves in STEP/DIR mode

#3 2016-04-04 19:20:34

Re: Movement randomly starts/stops during moves in STEP/DIR mode

#4 2016-04-04 19:33:37

Re: Movement randomly starts/stops during moves in STEP/DIR mode

#5 2016-04-04 19:58:05

Re: Movement randomly starts/stops during moves in STEP/DIR mode

#6 2016-04-04 20:02:02

Re: Movement randomly starts/stops during moves in STEP/DIR mode

#7 2016-04-04 20:35:43

Re: Movement randomly starts/stops during moves in STEP/DIR mode

#8 2016-04-04 20:44:58

Re: Movement randomly starts/stops during moves in STEP/DIR mode

#9 2016-04-04 21:15:37

Re: Movement randomly starts/stops during moves in STEP/DIR mode

#10 2016-04-04 21:46:12

Re: Movement randomly starts/stops during moves in STEP/DIR mode

#11 2016-04-04 22:04:14

Re: Movement randomly starts/stops during moves in STEP/DIR mode

#12 2016-04-04 22:30:10

Re: Movement randomly starts/stops during moves in STEP/DIR mode

#13 2016-04-05 15:59:58

Re: Movement randomly starts/stops during moves in STEP/DIR mode

#14 2016-04-05 20:11:48

Re: Movement randomly starts/stops during moves in STEP/DIR mode

#15 2016-04-05 20:13:20

Re: Movement randomly starts/stops during moves in STEP/DIR mode

#16 2016-04-05 20:42:06

Re: Movement randomly starts/stops during moves in STEP/DIR mode

Board footer