We've never used the JTAG pins on the Duet, so when we needed to revise the layout of that area to reduce EMI, we were happy to remove the connector. If we wanted to do hardware debugging now, we would use Serial Wire Debug instead of JTAG, as we do on Duet 3. For Duet 2 we'd need to build a firmware variant that doesn't reprogram the bus matrix to use the SWD pins as GPIO pins.
@dc42, Of course, you can post it on other sites.
The PTFE tube length is 280mm from extruder fitting to effector fitting.
This is significant improvement comparing to my mini KOSSEL's 450mm.
I corrected the link of the carriage view, the 4th video.
I attached a metric ruler on the 4th rail. So you can see how far and fast the extrude carriage moves up and down when effector is traveling the same z_height XY plane.
My current setup is as follows
U_axis rod Length is 300, U_tower position M669 X0 Y-100.
The carriage moves dully relative to XY position if the U_axis rod length
is set high(ex. X665 L358:358:358:600), whereas the movement is very rapid and far when U_axis rod length is set low (ex. X665 L358:358:358:300).
If I set the rod length too short (for example 200mm), the effector cannot reach U_axis' opposite(diagonal) edge. And the carriage moves too fast enough to skip steps. Firmware restricts the movement.
The ideal U_tower position seems to be the center[M669 X0 Y0] given that fitting do not wear out and the PTFE tube don't flex too much. I will try this when I am ready for gimbals similar to ZATSIT's FlyStruder.
@mawildoer said in Advice on adding plasma torch height control:
Just a quick update on this one. I've done some testing very specifically on the EMI induced in a shielded wire taped adjacent and in very close proximity to the plasma cable. This test cable is a CAT 6 Ethernet cable, where each pair is foil shielded and the whole cable is braid shielded.
Also note that I didn't actually conduct everything in the following order, but I thought it made more sense to present it this way.
I got some interesting results (and way, way more noise than anticipated).
FWIW, I've been investigating making a plasma CNC as well, and have noticed
VERY important not to use a HighFrequency arc starting machine, these DEFINITELY will fry CNC electronics, pilot arc start are the one to use
Many cheaper Chinese plasmas have a s*** load of EMI noise, even one page goes directly to prohibit the use of certain plasmas (including the make of the one you are testing) with their CNC frame: http://www.langmuirsystems.com/plasma-cutters
by the way, their FAQ has a load of interesting info too
For my part, I'm also investigating an inductive probe to do the z-correction, instead of Torch Height Control, because I would prefer to completely isolate the CNC from the plasma (that said, would still need to attach the torch on/off M3....), but am also worried about EMI, but directly from the arc - if the inductive sensor is to be close enough to be useful to change height at the nozzle... if the sensor gets affected, it will incorrectly change the z-height... not convinced yet that it would work, probably THC would be better as is "spot-on" the nozzle...
Found it. Although the indexer was enabled in global settings with correct values I had to go to
Project -> Properties -> C/C++ General -> Indexer
and tick Enable project specific settings.
All of the so called project specific settings are absolutely identical to the ones of the global indexer but now it works.
@dc42 said in How are the axis coordinates supposed to be set when homing?:
@bondus said in How are the axis coordinates supposed to be set when homing?:
I don't need to tower to be able spin 360 degrees, it would tangle the cables. If you do want the tower to rotate multiple laps the cartesian->motor transform function would have to keep track of what lap you are on and select the appropriate stepper position.
RRF already does that for you, if your kinematics returns true from the call to IsContinuousRotationAxis for that axis.
Neat. It's implemented very simple, nice.
I can see that the Scara model makes heavy use of that. You can build some very strange Scaras.
@dc42 I figured it was something like that. It was easily fixed by changing M208 Z to a higher value, it's just a prototype so far.
I guess I should implement LimitPosition() as well. Just a like a delta the possible reachable coordinates narrows when you get above a certain Z, the upper sled would run out of rail.
But for now the firmware is good enough to keep my wobbly prototype running.
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.
@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.
Looks like your connection to Duet3D was lost, please wait while we try to reconnect.