Quote
arthurwolf
I hear your web interface is very nice too. Do you have screenshots of it somewhere ?
There is a screen shot of one of the pages in my blog entry at [miscsolutions.wordpress.com] about half way down (click on the image to get ot full size). I didn't write it, but I did add the dual-head support. The Print page displays a graph of progress, gives estimated end times, and allows the speed and extrusion factors to be adjusted. Another Ormerod user (zombiepantslol) is doing an updated web interface that should be more suited to small screens on tablets and smartphones.
Quote
arthurwolf
Quote
dc42
AFAIK it's also the only firmware that calculates the step pulse times on a delta properly.
We actually want to try to implement that ( we are currently moving towards per-step acceleration, per-step IK is next on the list ).
I'm a bit lost in your project's structure, could you point to me where you do that in your code ?
Gcodes for processing are fed to the Move class. The Move class fills in a DDA record for each new move by calling the Init function, does lookahead to adjust moves already in the queue as needed, and adds it to the queue. When a DDA record is getting close to being executed, Move calls Prepare on it, which freezes it (i.e. no more lookahead adjustment) and computes some parameters that will be needed by the ISR. Each DDA record has a DriveMovement struct for each possible drive, which stores the parameters for the way that drive needs to move. The actual per-step acceleration and precise delta movement are computed in CalcNextStepTime.
btw the overall architecture is not of my design, it's what RepRapPro wrote - although I have rewritten most of Move and DDA, and I wrote all of DriveMovement.
There is code for extruder elasticity compensation in CalcNextStepTime for extruders. This adjusts the extruder steps by an amount proportional to the extrusion speed, to try to compensate for the springiness of the filament in the Bowden tube and therefore avoid the classic over-extrusion at corners and hairpins, where the head slows down and speeds up again. But on the Ormerod at least, it doesn't work as well as I had hoped. So I may remove it. Someone else suggested just advancing the extruder movement a little compared to the axes. I could do that if I separate the DriveMovement structs from the DDA, so that movements for more than one move can be active concurrently.
btw ignore the 'delta' branch in my repository, that's old code now. My 'dev' branch is where delta (and all other development) happens now.