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.

@martin, updating the BuildInstructions page woud be best.

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. 🤦

OK thanks.

@dc42
No, you are so right in that.
Also a working reception from the panel due indicated that i had no reception from the duet .
But one step forward, and learning a lot.

@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.

Hang on, my bad, Miss read one of the console logs and recorded the derivative, rather than Dead time!

Sorry!

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

Yep, that was the problem. I knew it was going to be something simple I was forgetting. I added single quotes around the file names in the post-build step and it worked. Thanks for the help.

@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?:

Hi,

Have you considered using a remote drive extruder like the Zesty Nimble?

Frederick

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.

Huh. Im idiot. Im forgot about it. Thnx

Thank you!

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.

I was afraid to change encoding in case it broke something. But with your recommendation I will do so.
That did the trick.
Thanks.

Thanks, exactly what I needed to know😀👍🏻

The initialisation in Platform.cpp enables the pullup resistors on all pins that the firmware supports as SPI CS pins.