Strange behaviour in G1 movement
-
Which kinematics are you using?
-
Sorry yes, a CoreXY printer
-
Ah, OK. I know S1 behaves differently on Linear Delta, which is why I asked.
-
Clearly it has something to do with the endstops. THey are a bit different than what I normally see. The LED on the Duet board is lit while the end stops are not touched, and go off when they are. The green led on the end stops then goes on.
Now I assumed, red is V3.3, black is ground and white is signal. That is how I wired them. -
@zesty_lykle I don't think end stops are the culprit. I think the only time that the end stop changes the speed is if you have an analogue type end stop such as DC's IR probe which can slow down the homing speed as the bed gets close to the nozzle. If you do the move as a stand alone command (outside of a macro) does it behave differently with and without the "S1" parameter?
-
Yep, With the S1 in the G1 statement it moves nice and quick.
Without, it is very slow.
All this is in the Gcode console.
This is the end stop used:
-
@zesty_lykle That's weird. Just checked my CoreXY and it's working as expected. Movement speed makes no difference whether I use S1 not. The only thing I came across which looks a bit like bug is if I use an "F" parameter, then change the default speed in DWC, then enter a command without an "F" parameter, the move will complete at whatever I speed I last set, regardless of what the default move speed is set to in DWC but this might be how it's expected to work.
So, a couple of things. I assume that you are using absolute co-ordinates, so in order to do G1 X150 Y150 Fnnn, and then repeat that, you have to move somewhere else in between those moves yes?
What do you have for your end stop configuration? Something like M574 X1 Y1 S1 yes?
It could be a DWC thing. Try upgrading to latest - same applies to firmware I guess.
-
@deckingman It is the expected behaviour. G0 always uses the default speed if nothing else specified, but G1/G2/G3 "remember" the last speed.
-
@catalin_ro Thanks. I knew that's how G1 normally works but I wasn't quite sure if DWC obeyed the same rules, (given that one can set a default movement speed under "settings" within the web interface). Can you confirm that the setting for move speed in DWC is only applied if no prior feed rate has been requested? Also, is that per DWC session if "Apply" isn't clicked?
-
@Catalin_RO I don't think that is true with RRF unless you are in CNC mode. G0 and G1 are identical in 3D printer mode IIRC.
adavidm
-
@adavidm I don't know why, but I recall reading posts mentioning that most slicers rely strictly on G1 commands. Initially G0 was identical to G1 in RRF. Now they are different in the feed rate that they use by default.
@deckingman DWC may mess pretty well quite a few things, especially when combining manual jogging with console commands. As far as I recall, the jog commands are implemented also through G1 (but, please, take this with a grain of salt! I haven't rechecked this matter lately), with the feed rate configured in the settings page. Any manually issued G1/G2/G3 will use that last feedrate if they have no F parameter.
-
I have confirmed that the endstop plug is wired correctly. All leads go into the correct connector, both on the endstop and on the board.
The fact that the LED on the board is on, when the endstop is NOT triggered makes me think there is something wrong in the config. But I cannot work out what is wrong.Unless it has absolutely nothing to do with the endstops. But then it is even more strange behavior.
One more thing, I have updated the firmware to the last version, so I am thinking hardware/config.
Lykle
Design, make and enjoy lifeCo Creator of the Zesty Nimble
-
Even with no endstops connected, I still have the strange movement. It will only move at speed if I add the S1 or S2 parameter. Otherwise it is crawling at a snails pace.
Lykle
Design, make and enjoy lifeCo Creator of the Zesty Nimble
-
@zesty_lykle Hi Lykle. Looking again at your picture of the end stop switch, it looks like it's just a microswitch with an LED associated with it. If it's normally closed, then current will flow through the LED. When the switch is triggered, it goes from normally closed to open so no current flows through the LED and it goes off. That's how I'd expect it to work. Can you confirm that your M574 is something like X1 Y1 S1? You could wire it to use the normally open contact in which case the LED would light when it triggers but you'd have to change your M574 from S1 to S0. It's generally best to wire them as you have so that if a wire falls off, then it'll look like the switch is triggered rather then having them normally open in which case if a wire falls off, it'll never trigger.
Either way, it's just a make/break switch and there is no "in between" condition. So I can't see how or why your problem can be caused by the switch or its configuration. If it was a Z probe and being used, then the situation is different.
-
@zesty_lykle Looks like we posted at the same time. So I think you've eliminated the switch as a likely cause. You say that you updated to the latest firmware, does that include the latest version of DWC?
-
It is a normally open switch.
I have downloaded the combined file and installed that.Nothing I do, makes a change in the behaviour.
-
@zesty_lykle That's really weird. So when an S1 parameter is used, the firmware is looking for a change of state of the end stop switch. But I've been through the complete list of G and M codes and can't see anything anywhere that might define a different speed when and S1 parameter is used.
Can you post your config.g and I'll compare it with my CoreXY config to see if anything leaps out at me.
-
Please post your config.g file.
-
-
Here is a long shot. I see you use mesh grid bed compensation. Also, your Z speed and accelerations are low (not saying there is anything wrong with that, just making an observation). So I'm wondering is G1 XY moves are slow because the mesh compensation is active and it's having to wait for the Z axis. Then maybe when the S1 parameter is present, it's classed as a homing move so any mesh bed compensation is not being acted on.
As I said, just a long shot - I don't use any form of flatness or level compensation so it might aslos explain why I can't replicate the behaviour on my machine.
