@dc42 Thanks for the hints. Got dev branch running, implemented a Kinematics and got the printer moving. It's moving, but it's not moving right. All the different coordinate systems and origins causes confusion, I need a thinking session with pen and paper
A good thing I discovered was to turn down stepper currents, a lot. I have pounded my endstops quite a lot.
@fcwilt, I need a rational? It's a fun project to get it running.
It is actually a very compact design, the arm can be folded into the tower when not is use. And if the bed is removable or foldable it will be easy to store.
The crane-arm itself has many potential flaws, if you get to far out the stepper has to move much faster than the print head moves, if you get too close to the tower the head moves very fast and the steppers has to be very precise. Proper calibration for non-perfect arms/tower can also be a challenge, but it should be easier than delta.
For most cases Delta and scara are probably better non-cartesian designs than this.
@Alexander-Mundy, I was a bit sloppy when I built them, they are all hand drilled, I might have to redo them at some point. But I used one as a template for the rest, so they are pretty equal at least. Z seems to be pretty straight and at 90deg to the tower when I move the Y motor.
I should get the arms CNC/laser/water/plasma cut, but this is good enough for now.
Hang on, my bad, Miss read one of the console logs and recorded the derivative, rather than Dead time!
18/01/2019, 09:17:08 M307 H1
Heater 1 model: gain 243.7, time constant 132.9, dead time 4.5, max PWM 1.00, calibration voltage 0.0, mode PID, inverted no, frequency default
Computed PID parameters for setpoint change: P21.6, I0.885, D68.1
Computed PID parameters for load change: P21.6
18/01/2019, 09:14:48 Auto tune heater 1 completed in 354 sec
Use M307 H1 to see the result, or M500 to save the result in config-override.g
18/01/2019, 09:12:46 Auto tune phase 3, peak temperature was 231.9
18/01/2019, 09:12:39 Auto tune phase 2, heater off
18/01/2019, 09:08:59 Auto tune phase 1, heater on
18/01/2019, 09:08:53 M303 H1 P1 S230
Auto tuning heater 1 using target temperature 230.0°C and PWM 1.00 - do not leave printer unattended
@doctrucker said in M104 depreciated? Slic3r gcode flavour?:
That makes sense thanks.
Is this just a RepRap/Duet firmware move or are you aware of the others considering the same moves?
Beginning to look like Slic3r and other slicers would benefit from splitting Marlin and RepRap Firmware on the gcode flavours options.
It doesn't really matter much (at least with slic3r). All I do (and what I've always done) is put the G10 active and standby temperatures for all the defined tools into the start gcode. Or more precisely, into a macro that is called from the start gcode. Then for multi colour prints, slic3r just puts Tn commands in the gcode file, so switching tools doesn't cause any issues as the active and standby temperatures have already been set.
@fcwilt said in Would This Require Custom Kinematics?:
Have you considered using a remote drive extruder like the Zesty Nimble?
That's another good option and one that I would have given serious consideration to if they had been available when I built my printer. Of course the OP would need 4 but the cost would be offset against the need for a second gantry.
About 0.5sec + 1 move.
Mhmm you're right in saying that's going to be a problem.
My plasma is remarkably forgiving in terms of crashed into the part so perhaps I'll begin with a sprung torch (to ensure it doesn't crash too hard) and focus on the other axes while I see how either modifying the baby steps/DDA goes.
Thanks once again for the help
@phaedrux said in M201, M204, & Slic3r Geometry Dependant Acceleration Control:
@dc42 How did your push for gcode syntax conformity play out? Ever get any buy in?
The Smoothieware devs agreed, but the Marlin devs ignored it. All I got was a complaint that the GCode wiki at reprap.org was hard to use because it had too many RRF-specific GCodes in it.
@dc42 Thanks that's enough for me to get a decent start on my gcode parser.
Other unasked questions relating to acceleration/deceleration may come out in the wash when I get to estimating travel time.
This is predominately an exercise to get back up to speed with Python, but also to better understand the details process.
Sounds good. I ended up figuring it out. I was missing the RRFLibraries repo in my project. I now have it up and running on both Mac and Windows. I did have to use the v2-dev branch of RepRapFirmware instead of master to get it to compile.
I was looking through the config.g file but wasn't sure what I might need in there. I was hoping there was a GCode command I could use, that makes life much easier
Thanks again, have an awesome holidays!
@dc42 sounds good. I guess the default behavior should work if I drop the T parameter. According to the Duet gcode docs, T defaults to 10 seconds for modes S0 and S1. I’m out of town and will test when I get back.
Unknown as the webapp was down and I don't have the LCD connected so I wasn't able to examine the state of the controller. I manually lifted the effector and power cycled the controller. The PETG was molten so it was still at or around operational temperature. I'll post the firmware version when I get home. Do you know if there are any debug options that can be enabled and if there are any crash logs available?
Ok, RTFM Some combination of M929/M111/M114/M122 might do the trick.
@ander said in Flying extruder with 4th axis:
I just received the lead screw, tomorrow i will change it so the 4th axis can move so much faster.
@dc42 , did you have any chance of working on the firmware?
i had to cut the 1.2m teflon tube that was going from the motor to the hotend to make the modification and now the printer is not working ever since.
I'm sorry, I won't have time to look at this until the 2.02 release is finished.