U-axis without limit
-
I have no idea how stupid my idea is, but you can try. As limiting command M208 must be after M584 command to work, you should try this:
M584 X0 Y1 Z2 E3
M208 (your limits)S0
M208 (your limits)S1
M584 U4And as i said, have no clue if its really works that way, so sorry wasting your time if it does not.
-
Have you tried giving it a maximum and minimum of 0?
-
Thank you for your ideas. I have testet them both. Unfortunately both do not work. With both I can only move from 0 - 200 then it stops. I assume, that 200 is the default limit.
Any other ideas? -
What for you using it? If you could define it as extruder, then you dont have limits. Only limit for extruder is temperature but you can always allow cold extrusion.
-
I did already try it as an extruder axis. But there are two big disadvantage:
- there is no possibility for a homing on an extrusion axis (as far as I know). And we need homing to know in which position the axis is.
- only relative movement is allowed, which is not the best for the application.
-
you could put a very high value in, such as 1000000. How infinite do you need it to be?
-
Yes, if there is no other solution, this may be what I will do. And maybe I can reset the position with G92 if it gets too high. But no limit would still be better...
-
one for @dc42 to point in the right direction
-
Moved to the firmware wishlist area for @dc42 to see.
-
I've added this to the work list for RRF 3.2. RRF already supports continuous rotation axes for certain kinematics, but at present there is no way to configure an axes as a continuous rotation axis manually.
-
Thank you for your answer. What kinematics do have continuous rotation axis? How can I choose it? Maybe I can make a work around, since the gcode is not generated by a slicer, but by a script code, which I made myself.
-
Continuous rotation axes can be created in the latest firmware builds from the v3.02-dev branch on github.
-
Hi, short of compiling my own firmware, is there an easy way to set up a rotational axis without a limit on a cnc ?
M550 PSPHINX CNC ; Set machine name
M552 S1 ; Enable network
M586 P0 S1 ; Enable HTTP
M586 P1 S0 ; Disable FTP
M586 P2 S0 ; Disable Telnet; Drives
M569 P0 S0 ; Drive 0 goes backwards
M569 P1 S1 ; Drive 1 goes forwards
M569 P2 S0 ; Drive 2 goes backwards
M569 P3 S1 ; Drive 3 goes forwards
M569 P4 S0 ; Drive 4 goes forwards
M584 X0:3 Y1 Z2 ; Apply custom drive mapping
M584 U4 S1M92 X400 Y400 Z400 U53.33333 ; Set steps per mm
M350 X16 Y16 Z16 U16 I1 ; Configure microstepping with interpolation
M566 X500 Y500 Z500 U5000 ; Set maximum instantaneous speed changes (mm/min)
M203 X3000 Y3000 Z3000 U10000 ; Set maximum speeds (mm/min)
M201 X150 Y150 Z150 U500 ; Set accelerations (mm/s^2
M906 X2400 Y2400 Z2400 U2400 I30 ; Set motor currents (mA) -
@tntjet they are supported in the latest betas of 3.2
-
The question is how ? im currently on 3.2.
-
@tntjet If only there were a list of changes.... Oh wait
https://github.com/Duet3D/RepRapFirmware/blob/v3-dev/WHATS_NEW_RRF3.md
New features/changed behaviour:
When new axes are created using M584, if no R parameter is specified then the default for axes ABCD is now rotational. Use the R0 parameter if you want them to be linear.
M584 has a new S parameter which specifies whether new axes created in the command are to be treated as linear (S0) or rotational (S1) for the purpose of feedrate calculation. This is separate from the R parameter, which specifies whether new axes are rotational or not. The default is to treat linear axes as linear and rotational axes as rotational. You only need to provide the S parameter if you want to change the way that the feed rate is applied.Does that make sense? I'm not a CNC user.
-
@phaedrux, im not looking at having an argument i have read the change log over and over as well as the dozuki info , the issue im having is my axis is named U (it works with the pendant this way) changelog spesifies A,B,C,D.
Exerp from dozuki
M584: Set drive mapping
ParametersXnnn Driver number(s) for X motor(s)
Ynnn Driver number(s) for Y motor(s)
Znnn Driver number(s) for Z motor(s)
Rn (optional, supported in RRF 3.2beta1 and later) 0 = axes creates in this command are linear, 1 = axes created are rotational. If not present, then RRF 3.2beta3 and later assume UVW are linear and ABCD are rotational.
Sn (optional, supported in RRF 3.2beta3 and later) 0 = axes created in this command are treated as linear in feedrate calculations, 1 = axes created are treated as rotational in feedrate calculations. See section 2.1.2.5 of the NIST GCode standard for how the feedrate is interpreted. Default is S0 for linear axes and S1 for rotational axes (see the R parameter).
U, V, W, A, B, Cnnn Driver number(s) for additional axes U, V, W, A, B and C (UVW available in RepRapFirmware 1.16 and later; UVWABC available in RepRapFirmware 1.19 and later; UVWABCD available in RepRapFirmware 3.0 and later).
Ennn Driver number(s) for E motor(s)
Pnnn Number of visible axes, defaults to the total number of axes configured.im looking for an unlimited rotational axis . as far as i understand Im required to compile my own firmware to make this happen , I am not capable of compiling firmware can anybody help?
-
Sorry was just trying to be funny not have an argument. Was just trying to help.
-
@tntjet said in U-axis without limit:
im looking for an unlimited rotational axis . as far as i understand Im required to compile my own firmware to make this happen , I am not capable of compiling firmware can anybody help?
I don't know why you assume that. You could install 3.2 beta 4 right now if you wanted to test with it.
@tntjet said in U-axis without limit:
the issue im having is my axis is named U (it works with the pendant this way) changelog spesifies A,B,C,D.
From my reading of the changelog, yes I think you would have to use ABCD for a rotational axis. How does it conflict with the pendant?
-
@Phadrux The pendant only recognises the axis if it is named U. A,B,C or D wont work
