Test print jittery head

Hi
Completed the build of my Rostock mini variant and after basic calibration ive tried a basic cube test print but the head seems to jitter. Its printing but instead of smooth straight lines it prints in almost what seems like a series of X/Y moves (very small)
Any ideas
Travel moves seem fast and smooth ( while i was calibrating) , its just when printing

Im using Marlin FW, Ramps 1.4 . Wantai steppers on T2 belts with 36 tooth drive pulleys

Thanks in advance

Do you have a graphical LCD?????

Quote
vreihen
Do you have a graphical LCD?????

No running from pronterface./ cura
Ive tried with simplify3D as well
I can feel the jitter in the stepper motors ...strange
Ive got delta segments down to 60 ...no difference

Did you tune the stepper drivers with a multimeter?????

Quote
vreihen
Did you tune the stepper drivers with a multimeter?????

Ill give that a try. They were on a cartisian printer previously and seemed to work fine.

checked the stepper drivers ...all working fine at a ref voltage of 0.7 VDC
tried lower and they stall at +/- 0.48VDC
tried raising them to 0.9 VDC ...no difference

While trying things out i noticed they also jitter per axis when homing

If , for example the effector is at the build plate and i click home all 3 axis run up to home smoothly and quickly fine
once they contact the micro switch they go down a little way then back up slowly and during the slow part they jitter
Ill try and video it ..strange

What are the normal accelration and jerk settings in Marlin for Rostock Mini ??
Thanks

i noticed that the same jittery motion happens during the slow movement part of the homing process
If you listen carefully you can even hear the juddering of the steppers ...low frequency sound.
[www.youtube.com]

The initial homing motion is fast and smooth then as per normal the axis move away from the micro switches then move back slowly till the microswitch is tripped again.
This is the same kind of jitter/ juddering im experiencing on slow print moves.

Im really lost as to what is causing this
Ive tried a couple of Marlin versions ( Rich Catells and the standard Marlin Delta) all give the same result.

All help / suggestions appreciated

Still plagued by this issue.
I was starting to doubt the steppers and drivers so i uploaded the Marlin test program ( the one that cycles all the outputs/steppers) Everything runs fine and smooth. The steppers are new from E3D so i doubt there's an issue there.
Must be something in the FW but i cant figure it out.

I suppose at least its a consistent issue. If i slow or speed up a print the juddering does too which is noticeable in the print exterior wall finish.

Is there anybody out there with a Rostock mini running Ramps 1.4 that would share their Marlin code and/or config.h file for me to try ??
Thanks

Why not try Repetier firmware? The web-based config tool will build your config by answering questions, and from many people's experiences it is slightly less taxing on the limited 8-bit CPU resources.....

Quote
vreihen
Why not try Repetier firmware? The web-based config tool will build your config by answering questions, and from many people's experiences it is slightly less taxing on the limited 8-bit CPU resources.....

Thanks for the reply
I think i may give that a go at the weekend when i have more time to experiment.
Im really quite frustrated by this issue because A/ Im an engineer & B/ ive been messing around with 3D printing for a good couple of years now.
This is my first delta and other than this problem it works fine . Absolutely no other issues ....Very frustrating

The jitter sounds like not enough CPU power to perform delta segmentation fast enough. The initial homing moves the head in the Z direction only, so no segmentation is needed. Marlin then fine-homes the 3 axes individually, so delta segmentation is required.

Even though you are not using a graphical LCD, are you sure the firmware isn't configured to drive one?

Personally, I would never run a delta printer with an 8-bit controller, although other people seem to get it to work as long as the board isn't also driving a graphical LCD. Modern 32-bit controller boards not only have enough processing power to run a delta printer much more easily, they also give you software control of stepper motor current, which makes getting the current right much easier. Some provide a web interface too.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
The jitter sounds like not enough CPU power to perform delta segmentation fast enough. The initial homing moves the head in the Z direction only, so no segmentation is needed. Marlin then fine-homes the 3 axes individually, so delta segmentation is required.

Even though you are not using a graphical LCD, are you sure the firmware isn't configured to drive one?

Personally, I would never run a delta printer with an 8-bit controller, although other people seem to get it to work as long as the board isn't also driving a graphical LCD. Modern 32-bit controller boards not only have enough processing power to run a delta printer much more easily, they also give you software control of stepper motor current, which makes getting the current right much easier. Some provide a web interface too.

Thanks for the reply

From everything ive read on the subject it does indeed sound like the "8 bit bug" is the issue. But from what ive seen fro other ramps users its not normally anywhere near this bad.
Other then making sure LCD isnt defined in the config.h file is there anything else i should check ??

Its nice to know that the 32bit option is out there but to be honest i wont be using the delta printer much as my old trusty Prusa Air2 performs much much better (TMC2100 silent stepper drivers and ball screws) and is more reliable and more importantly i have the choice of materials and am not bound by the shortfalls of bowden extruders.
Thats not to say this problem doesnt need fixing :-) and i dont give up easy
Cheers
Phil

Quote
dc42
...
Personally, I would never run a delta printer with an 8-bit controller....

Oh please. That's like saying: "Personally, I would never run a delta printer with blue PLA printed parts...". What does the number of bits of the MCU have to do with anything?

The vast majority of deltas built up until now are running on 8-bit controllers, and Johann Rocholl designed and built both the Rostock and Kossel prototypes with a standard ARV (8-bit) Arduino.

And suggesting that bigfilsing's printer problems are caused by having an 8-bit controller without even having properly diagnosed the issue is just ludicrous.

First determine what the cause of the problem is, don't you think so?

Quote
AndrewBCN
What does the number of bits of the MCU have to do with anything?

The speed of the cpu has everything to do with whether the delta calculations are being done fast enough. 32-bit processors are faster than 8 bit ones because (a) they process more bits at a time, which is 4x faster when you are dealing with 32-bit data such as motor endpoints and floating point values, and (b) current 32-bit mcus run at substantially higher clock speeds than 8-bit mcus such as the atmega2560.

I have seen several reports on this forum of people having problems with lack of processing power when using Arduino/RAMPS to run a delta - it is a common problem. The solutions involve compromises such as not using a graphical LCD and reducing the number of segments per second. Rather than have to make such compromises, it is surely better to provide enough processing power in the first place - as well as getting rid of the tricky motor current adjustment by using software control of motor current.

Edited 1 time(s). Last edit at 03/17/2015 12:30PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Will using blue printed parts help :-)
Just kidding

I think the on the fly calcs needed for running a delta smoothly are indeed pushing the limits of the classic 8 bit Arduino based boards and reports in the forums would seem to confirm this.
However
Im not using an LCD panel at all and reducing the delta segments has no noticeable effect which leads me, somewhat logically, to think that while the symptoms of my issue are very similar
in nature im not experiencing the "typical" CPU problem.
What i found interesting was that when i increased the speed the problem remained just at a higher frequency. In itself not groundbreaking but if i was having CPU handling issues it should have
worsened considerably
All food for thought i guess
Cant wait to get to the bottom of this and kick myself for not figuring it out earlier

Quote
dc42
Personally, I would never run a delta printer with an 8-bit controller

When the option is to use an 8-bit controller, or write my own @%(* firmware, guess what? I'm going to use an 8-bit controller.

I have a smoothieboard on order-- although it's form factor won't play nicely with my delta (and it didn't support Deltas this time last year). Some of the artifacts on Delta smoothie prints have me wondering if it's ready for Delta still. The Azteeg X5 has a nice form factor, but until recently, has had no useful LCD options for my printer (Why Smoothie doesn't support the discountreprap smart controller is beyond me).

Your branch of the RepRapPro firmware seems to be doing nicely, and I have a sneaking suspicion that your branch of the RepRapPro firmware is probably the single best firmware available for 3D printing right now. I can't prove that, since I can't do comparison testing but... but it didn't support Deltas when I built my printer a year ago, and the the Duet doesn't appear to have a distributor in the USA.

In the 10 months or so since I built my printer, I've made some very nice prints, some very bad prints, but generally speaking, my printer produces objects that look like they should when I hit "Print". I should probably comment that I'm running Repetier firmware with 180 segments, and usually at a top speed of 60mm/s due to hardware limits.

MANY people have 8-bit controllers on their Delta printers, and print just fine with them. Yes, 32 bit is better, but 32 bit for delta has only been viable for 3-6 months.

Quote
bigfilsing
Im not using an LCD panel at all and reducing the delta segments has no noticeable effect which leads me, somewhat logically, to think that while the symptoms of my issue are very similar
in nature im not experiencing the "typical" CPU problem.
What i found interesting was that when i increased the speed the problem remained just at a higher frequency. In itself not groundbreaking but if i was having CPU handling issues it should have
worsened considerably

I wonder whether the problem might be that lookahead is not working properly, i.e. the firmware is doing the segmentation fast enough but it is not joining the segments together smoothly?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
grat
The Azteeg X5 has a nice form factor, but until recently, has had no useful LCD options for my printer (Why Smoothie doesn't support the discountreprap smart controller is beyond me).

I've been running an RRD GLCD clone with my Azteeg X5 Mini (V1.0) since last fall, and it most certainly *is* supported in Smoothieware if you roll up your sleeves and make your own adapter cables. Granted, it would have been nice if the Smoothie folks made an official adapter, but Uberclock has filled that void and I will have it in my hands tomorrow if the USPS doesn't let me down. The Google Deltabot group purchase cleaned Uberclock out of the adapters, so there may be a wait for the next batch. I would never expect RRD GLCD support on an Azteeg board, since they make the VIKI LCD interface.....

Quote
vreihen

Quote
grat
The Azteeg X5 has a nice form factor, but until recently, has had no useful LCD options for my printer (Why Smoothie doesn't support the discountreprap smart controller is beyond me).

I've been running an RRD GLCD clone with my Azteeg X5 Mini (V1.0) since last fall, and it most certainly *is* supported in Smoothieware if you roll up your sleeves and make your own adapter cables. Granted, it would have been nice if the Smoothie folks made an official adapter, but Uberclock has filled that void and I will have it in my hands tomorrow if the USPS doesn't let me down. The Google Deltabot group purchase cleaned Uberclock out of the adapters, so there may be a wait for the next batch. I would never expect RRD GLCD support on an Azteeg board, since they make the VIKI LCD interface.....

I didn't say GLCD. I said the smart controller, with the 4 line text display. For form-factor / aesthetic reasons, it's what I have on my Kossel Clear, and I've been told by Arthur Wolf, that while the pinout is the same as the GLCD, the code isn't, and no one has written it.

Not surprising the code is different, since it's a 20x4 display instead of a 128x64 dot matrix.

I'm also expecting a smoothieboard with GLCD and adapter board. As for the X5, the viki2 is a fairly recent addition-- I'm not sure if it's the same size as the 20x4 RRD or not.

Quote
grat
I didn't say GLCD. I said the smart controller, with the 4 line text display. For form-factor / aesthetic reasons, it's what I have on my Kossel Clear, and I've been told by Arthur Wolf, that while the pinout is the same as the GLCD, the code isn't, and no one has written it.

I keep forgetting that RRD also made the LCD-2004. Is it a parallel LCD that might work with the Universal Panel Adapter?

https://github.com/wolfmanjm/universal-panel-adapter

One of the revisions on the VIKI2 was changing it from a 20x4 to a graphical LCD. I don't know the size, but just saw that Panucatt finally has the VIKI2 in stock.....

Quote
vreihen

Quote
grat
I didn't say GLCD. I said the smart controller, with the 4 line text display. For form-factor / aesthetic reasons, it's what I have on my Kossel Clear, and I've been told by Arthur Wolf, that while the pinout is the same as the GLCD, the code isn't, and no one has written it.

I keep forgetting that RRD also made the LCD-2004. Is it a parallel LCD that might work with the Universal Panel Adapter?

I don't know. I've gotten conflicting answers.

I verified from the schematics that it uses the exact same pinout configuration, with the same data lines as the GLCD, so my assumption is they both use the same bus and protocol, but I would expect the commands for displaying data to be different. It *should* be nearly trivial to implement, but apparently no one has bothered. Maybe now that I've bought a smoothieboard, I'll take the time to dig into the code for both Repetier and smoothie, and see if the support can be ported over.

I should also mention that the universal panel adapter is a pet peeve of mine-- For someone who builds arduino projects all the time, I'm sure there's enough information there to construct one. For someone who primarily does software, but is mostly a novice at building hardware, the information there is very sketchy (no pun intended), and I haven't found any blogs or forum posts where someone has actually built one and documented the process.

So ive tried a few more things
Different PC ( laptop) and USB cable in case communications were the issue = No change

Of course the feed back and conclusions above seem to point to the handling of delta segments so thinking back to my build i revisited the diagonal rod length again.
At the time i made carbon fiber rods with traxxis ball ends and made them 217mm long. I really cant remember why 217 but it was after considerable research on the net.
I think at the end of the day i wasn't absolutely sure so went with a figure i gathered from somewhere.

So to revisit it i have downloaded the openscad files and reconfigured the config to my build it tell me i should have diagonal rods of 204 mm
so my questions are is it possible that my 217 rods are the cause of the problem ??
and if i redo them ( which i definitely will) should i indeed go to 204 or possibly shorter ( i always thought they looked a bit long compared to pictures and videos ive seen).
Im sure i had all the data correct in Marlin config.h but maybe the 13mm oversized rods has pushed the delta calcs into strange territory

My layout is as per the original Rostock mini with a tower radius of 142.88 for the 8mm smooth rods

All input appreciated
CHeers

Quote
bigfilsing
So ive tried a few more things
Different PC ( laptop) and USB cable in case communications were the issue = No change

Of course the feed back and conclusions above seem to point to the handling of delta segments so thinking back to my build i revisited the diagonal rod length again.
At the time i made carbon fiber rods with traxxis ball ends and made them 217mm long. I really cant remember why 217 but it was after considerable research on the net.
I think at the end of the day i wasn't absolutely sure so went with a figure i gathered from somewhere.

So to revisit it i have downloaded the openscad files and reconfigured the config to my build it tell me i should have diagonal rods of 204 mm
so my questions are is it possible that my 217 rods are the cause of the problem ??
...

No. Simply put, having 13mm longer than calculated diagonal rod lengths could never cause jitter in the movement of the head. The problem and the solution is elsewhere, and my guess is firmware configuration.
As has been suggested above, configure Repetier online and then flash it to your Arduino just to check whether or not the problem is firmware related. You'll either solve the problem or in the worst case, at least you'll know it's nothing to do with the firmware.

Thanks for the reply
I didnt think the 13mm would cause the issues i have
Repetier ......Yup that's the plan at the weekend

Tonight i was messing around with my Prusa Air2 and so i transplanted & flashed the ramps & arduino mega from that . Same result
I also tried a clean version of Marlin ( of course with some config.h adjustments for endstops etc ) same result

Ive tuned the extruder a bit more and prints are getting better...no longer over extruding by much and even without a fan the bridging on a hollow 20mm test cube is pretty good
But the head judder is still visible in the print wall if for example, i print a cube.
The irony is that if for some reason you wanted that effect ...maybe with a wood filament ...it would be difficult to create. It almost looks like a weave !!

Edited 1 time(s). Last edit at 03/19/2015 02:05PM by bigfilsing.

Could you post a photo closeup of the effect on a printed piece?

Is the judder at a constant rate, or does the judder happen more often when you move the head faster?

Before I converted my Mini Kossel to Duet electronics, I had it working with RAMPS/Marlin and I didn't get that judder - at least at typical printing speeds. The version of Marlin I was using is at [github.com]. You might like to try that version, after making any essential changes to the configuration file to account for differences between your Rostock and a Mini Kossel.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
AndrewBCN
Could you post a photo closeup of the effect on a printed piece?

Sure ..ill get some posted asap after work

Quote
dc42
Is the judder at a constant rate, or does the judder happen more often when you move the head faster?

Before I converted my Mini Kossel to Duet electronics, I had it working with RAMPS/Marlin and I didn't get that judder - at least at typical printing speeds. The version of Marlin I was using is at [github.com]. You might like to try that version, after making any essential changes to the configuration file to account for differences between your Rostock and a Mini Kossel.

It follows the print speed.
I really slowed down the print speed thinking if it were the delta segments calc issue, printing slower would allow the Mega more time to deal with the print but the juddering is still there...just slower.
Ill post some pics after work & ill try the Marlin version you posted ...thanks

Test pictures

E3D V6 hotend with stock 0.4 nozzel
Verbatim Black 1.75 PLA @ 195 DegC
test cube 20 X 20 X 10 mm
printed hollow with 0.8mm wall thickness
Print stopped at top when bridging starts
You can already see the judder in the brim thats laid down at 10mm/s


Other pics attached

Now going to try the dc42 suggested Marlin and then Repetier

Edited 1 time(s). Last edit at 03/20/2015 12:00AM by bigfilsing.

HI
Before trying more FW options i also printed a cylinder to see what something other than straight lines would produce. Judder still visible




Cheers
Phil