As part of a string of experiments to do with speed and quality, I wanted to see what the effect would be of pushing the number of kinematic calculations per second up a bit. Initially I did not see a lot of difference, but after pushing it to 500 I saw a difference in the accuracy of the head movement.
This was the end effect though…
The printer actually slowed down significantly to cope with the maths, and the feed rates did not translate. It also seem that some fill lines got left wayside…
To increase speed and quality together, the processing power of the electronics needs to be upped, or some form of preprocessing needs to be performed, perhaps with proprietary polar gcode that the printer can use raw. I’ll be looking into the latter some time in the future.
In the mean time the firmware gives a good balance of quality and speed, allowing brisk non-printing moves, while quality is user selectable by the printing speed.
Draft printing redefined…
From what I understand The rostock delta is based on Marlin firmware which pre calculates discrete steps for each move before moving. The original Helium frog delta used on the fly calculations which seemed to work quite well. The main loop cycles as fast as possible and corrected the actual position to expected position in a closed loop. I expect line to line accuracy to go down as you speed up, but not what you are seeing here. Are you sure the code calculates on the fly or just pre calculates over 500 steps before moving. This would cause the problems you see and slow the robot down.
Hi Martin,
My marlin code is forked from Johann Rocholl’s Rosstock code. It cuts the gcode into 200 x seconds bits and this gets processed on the fly in the loop.
After returning the calculations per second to the original 200 I am getting my higher quality prints again.
I remember being slightly annoyed at myself when you posted your helium-frog SCARA design online, after searching and not finding any on line. I have been working on an initial concept for about half a year before that. Not successful al the time though.
Cheers,
Quentin
How much difference would the use of a different arduino ‘compatible’ platform make? I ask as I have a chipkit uno32 which is PIC32 based while trying to remain arduino compatible, and I understand is somewhat more powerful than the arduino uno platform. No, I haven’t tried compiling the code – I wouldn’t have any way of testing it currently…
I am entertaining the idea of modifying RAMPS to use Arduino Due, 32bit ARM based with the same footprint as Arduino Mega.
Will let you know of progress.
Taking a quick look at RAMPS schematic, and it looks like a lot of stuff can be moved across to 3.3V pretty easily. The A4988 stepper controllers are already 3.3V capable. The thermistors should just move across to 3.3V, as can the MOSFETs used for heaters/fans. The datasheet seems to indicate they’ll be fine for in excess of 30A at 3.3v. That just leaves the servos, which might well need a MOSFET and a pullup to keep them working.
That’s just my quick view of RAMPS…
My thoughts exactly. An added bonus is that nobody ever use the servos for 3d printing anyway.
The biggest downside is, of course, the code. I hadn’t realized just how tightly coupled it is to the underlying architecture. It seems to make more sense to move to some kind of hardware abstraction model so that changing the processor only requires changes to the abstraction, rather than the main code.
Hopefully that is something that will change soon. Arduino is working hard to make current arduino sketches compatible to Due… we’ll see how well they do! In the mean time I am giving my Mega a run for it’s money 😉