Duet DC42 G1 negative command S0 goes home!

Centre point (home) is located in the middle of my printer at the moment!

from coordinates (0,0,0)

When using G1 f1000 x-10 s0 ;carriage does not move "backwards-negative"
When using G1 f1000 x10 s0 ; carriage does move "forwards-positive"

if at coordinates (-n,0,0) and sending:
>>> G1 x-n s0 ; the carriage will always go to home!

where n = a number

Why is this and can this be easily fixed?



On a side note: why is it when the endStop is triggered say on the x axis with a ">>>G1 f2000 x7 e:10:0:0:0 s1" command the extruder stops moving as well?

Thanks

David

That's hard to answer, because you haven't said what type of printer it is (Cartesian, Delta, or CoreXY).

On a Cartesian or CoreXY printer, by default the negative X and Y movement limits are zero. Use the M208 command with the S1 parameter to change this.

On a Cartesian or delta printer, any homing (i.e. G1 S1) move is terminated when the last endstop switch that is active for that move is triggered. On a CoreXY it's the first endstop switch that terminates the move.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hi DC,

It is a Cartesian printer with 7DOF, ie: rotation around each axis + an extruder

Thank you, I had forgotten that I had set M208 S1 to be (0,0,-10).

I am not using "homing commands" during this test, but the extruder (or an axis ) stops when an end stop is triggered and the coordinates are more negative than M208 S1 command, which now makes sense.

I am thinking I have miss configured the end stop settings M574 for the additional DOF, well I have not set them all as I need to purchase more micro switches, hence they stop!

The additional M574 commands for the duet expansion board has not been specified on G-Code Wiki. So far I have:

M574 X1 Y1 S0 ; Set endstop configuration (Y AND X, at low end, active LOW)
M574 Z1 S1 ; SET Z TO BE LOW-END ACTIVE HIGH

Does the command also include the send stops for the expansion board as shown on Think3DPrint3D Blog, is so how does it work?

M574 E1:1:1:1:1:1 S1 ?

or

;M574 E0 S1 (this is actually my extruder)
;M574 E1 S1 (this is unused)
M574 E2 S1 (alpha)
M574 E3 S1 (beta)
M574 E4 S1 (gamma)
;M574 51 S1 (this is unused)

I will happily make the necessary wiki edits once I know!

Thanks

David

The way the soft endstops work is that for any ordinary G0 or G1 move (i.e. without S1 or S2), for any axis which has been homed or homing simulated by sending G92, the end point of that move along that axis is limited to the value configured by M208, unless M564 has been used to allow movement outside the limits.. That's why the extruder stops at the same time: it's because the end coordinates of the whole move have been changed.

The XYZ endstop switches are ONLY used to terminate a G1 S2 move. Only the endstop switches for axes that are moving are enabled. At other times they are inactive.

When I implemented M574 I didn't give any thought to more than one extruder endstop switch being used, because only extruder 0 endstop connection has any function in RepRapFirmware currently (it is used for connecting a Z probe having a digital output). So at present you can't configure the endstop inputs on the additional extruders.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thank you for your informative advice,

I am still having issues with the web interface, I do not believe pronterface can handle sending the macro files, but I could include some pre written g-code in my slicer to home the rotary axis....

I do like your approach using ternary objective-C operators for your M574 case, although if I am going to get the end stops up and running I am not sure what the best approach would be!

If I am correct I believe that the GCodeState::homing uses the macro approach (without the need of the web interface ).

Currently my extruders are acting as the rotary axes, this is a simple method that seems to work quite well, tho I have no calibration ie (Endstops!) for these DOFs...

So, I could modify the AXES number (platform.h) and the GCodes::axisLetters[AXES], but I am unsure if the planner and platform would allow such a modification?

For Example:
As there is no drive mapping feature yet, I am assuming that the #define AXES 3 would get assigned sequentially to the steppers: P0, P1, P2 for X, Y, Z then the remaining DRIVES (ie 9-3 = 6) are assigned to the P3,P4,P... which then can be correlate to the tool setup (in my case) M563 P0 D5:2:3:0 H1, (the wiring for the duet's duex isn't in order!).

If I add extra axes X, Y, Z ,A ,B ,C would the remaining drives be assigned as extrudes, would the planner still be functional, (would this activate, assuming I configure some of the pinouts, nope they are already #define END_STOP_PINS {11, 28, 60, 31, 24, 46, 45, 44, X9} ) the endStops for A, B, C ?

Where do you use to write to data registers for the PWM, ADC, DDRs, USART, DMA, I cannot seem to find much at all, if anything, unless it is handled by arduino.h! ?
I am using Atmel Studio to view your fork of the reprap firmware, it will not compile mind missing "lwipopts.h" file!
I also have the binary file! what I am looking at now is the latest version from your github.

If you can think of another way I can calibrate, please I am all ears(well eyes in this case).

Thanks again DC

David

1. Yes homing uses macros: homex.g, homey.g, homez.g, and homeall.g.

2, I think your best bet is to increase AXES and E0_AXIS to 6, and update axisletters. That should take care of most things, but there may be a few other changes needed The planner should be OK with this because in most respects it treats axes and extruders the same.

3. Most of the I/O is handled in Libraries/SamNonDuePin and in the Arduino code. There is also some direct I/O done in class Platform.

4. RepRapFirmware is normally compiled in Eclipse. File lwiopts.h is in the Libraries/lwip subtree.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].