New experimental firmware 1.19beta11
-
That's right, it's a bug in some versions of DuetEthernetFirmware 1.19beta, fixed in 10+2. If you are affected then you will need to update to a new version using SAM-BA or Bossa/bossac 1.8. Although it's possible that if you enable FTP on your old system and transfer a file, you might be able to update over the web after that.
-
BTW. I started seeing:
"Can't open 0:/sys/oem.json to read, error code 4" since I updated everything to latest and greatest. Is this an issue with DWC update? -
I guess you must have a USB host connected. You can ignore that message; but I'll discuss with chrishamm how we can get rid of it.
-
I guess you must have a USB host connected. You can ignore that message; but I'll discuss with chrishamm how we can get rid of it.
I don't – I did at one point when I was trying to debug liner motion. I actually couldn't leave USB connected as the board really didn't like it with ethernet. Basically the ethernet connection would drop out and I only had USB connectivity. I ordered a USB isolator as I want to have that option open to me. I am assuming ethernet issue was caused by a ground loop of some sort.
Y
-
Ethernet is isolated, so I'm surprised it was affected by USB.
See https://duet3d.com/wiki/Important_note_on_using_a_USB_connection for advise on using USB.
-
Ethernet is isolated, so I'm surprised it was affected by USB.
See https://duet3d.com/wiki/Important_note_on_using_a_USB_connection for advise on using USB.
Yep I saw that. That's why I have a USB isolator coming (Amazon says tomorrow) – it definitely didn't like it, and all the lights on Ethernet port went out and board just fell off line, didn't crash or do anything like that, but wasn't happy, it seemed to be either or, as soon as I disconnected the USB -- ethernet came back, so I only used it sparingly since with DWC and the LCD -- USB is basically only needed for emergencies.
I usually run OctoPrint, the only functionality I'm missing with DWC is camera, but I see it supports a URL, so I can add something, and remote power/shutdown, which I can accomplish by adding 5V standby power and use a simple relay board to power on the main PSU -- so I will look into that later.
I have my OctoPrint instances setup to e-mail me when a print starts and when it ends (with a picture), it also notifies my central web server which machine started and/or finished printing -- the central server then starts polling every minute for print progress. They also handle automatic power off of the printer PSU 20 minutes after a print job is done -- unless a new one is started. I'll need to figure out how to do that with Duet -- I may end up adding Pi0 with a camera or something similar to get all those functions. -
I've tried installing 1.19 beta 11 and it fails to calibrate my Delta very much the same as in this (not mine) video https://youtu.be/lgSrFK_ke1M.
Any hints how do I fix that? -
I've got crazy problem since upgrading earlier from1.19beta8 to 1.19beta11(experimental version to fix fan7 issue). My CoreXY X an Y axes have become reversed but swapping the plugs doesn't change the behaviour!
My mapping in config.g is this
M584 X0:3 Y1:4 Z2 E5:6:7:8:9So I turned off the power to the Duet, swapped drive 0 with drive 1 and drive 3 with drive 4 thinking that I've swapped X with Y. But when I press X+10 in Duet, the machine still moves Y+10 and vica versa when I do Y+10 it moves X + 10. I trebble checked against the wiring diagram. By default drive 0 is X and drive 1 is Y, but swapping X and Y motors makes no difference - the wrong axis moves (but in the correct direction).
Then I tried putting the wiring back to standard and swapping the motors by changing the mapping to this
M584 X1:4 Y0:3 Z2 E5:6:7:8:9Still the same X+10 moves in Y and Y+10 moves in X.
How can this be. More importantly, how can I fix it?
Edit. Can;t be sure it worked in 1.19beta8 as I didn't have any drives re-mapped.
Further Edit. Could this issue also be the reason why on DWC only extruder drive 1 and "All" work?
-
Hi Ian,
The X and Y motor assignment changed at beta 9. However, it's just not possible that the head moves in the wrong directions in exactly the same way when you swap them (either in the wiring or in the M584 drive assignments). Please check again what they are doing. I think you will find that one of them is moving the wrong axis in the negative direction, not positive. In which case, you need to use M569 to reverse one of the motor directions.
-
David,
You're right. There is a slight difference when I check carefully.
X-10 std wiring = Y-10, reversed wiring = Y+10
Y-10 std wiring = X-10, reversed wiring = X-10 (the same)
X+10 std wiring = Y+10, reversed wiring = Y-10
Y+10 std wiring = X+10, reversed wiring = X+10 (also the same).I'll play around with motor directions to see if I can fix it.
-
I've tried every combination of direction. The best I can get is that X moves as it should but Y moves positive instead of negative. It's too late and I'm too tired. I''ll try gain tomorrow after I've slept on it.
-
You need to use what you are calling reversed wiring.
-
OK. So with "reversed wiring", that is to say the X motors were connected to drives 0 and 3 and the Y were connected to 1 and 4 so now with "reversed wiring" X motors are now connected to drives 1 and 4 and Y motors are connected to drives 0 and 3.
I've tried all 4 combinations of motor direction and here is what I get.
P0 S1, P1 S0, P3 S1, and P4 S0.
X+10 gives Y+10 - wrong
X-10 gives Y-10 - wrong
Y+10 gives X-10 - wrong
Y-10 gives X+10 - wrongP0 S0, P1 S0, P3 S0, and P4 S0
X+10 gives X+10 -OK
X-10 gives X-10 - OK
Y+10 gives Y-10 -wrong
Y-10 gives Y+10 - wrongP0 S1, P1 S1, P3 S1 and P4 S1
X+10 gives X-10 -wrong
X-10 gives X+10 - wrong
Y+10 gives Y+10 - OK
Y-10 gives Y-10 - OKP0 S0, P1 S1, P3 S0 and P4 S1
X+10 gives Y-10 - wrong
X-10 gives Y+10 - wrong
Y+10 gives X+10 - wrong
Y-10 gives X-10 - wrong.That's all the possible combinations.
-
Support 2 additional external drivers connected to the CONN_LCD socket
Where can I find more information about this feature?
-
Support 2 additional external drivers connected to the CONN_LCD socket
Where can I find more information about this feature?
-
OK. So with "reversed wiring", that is to say the X motors were connected to drives 0 and 3 and the Y were connected to 1 and 4 so now with "reversed wiring" X motors are now connected to drives 1 and 4 and Y motors are connected to drives 0 and 3.
I've tried all 4 combinations of motor direction and here is what I get.
P0 S1, P1 S0, P3 S1, and P4 S0.
X+10 gives Y+10 - wrong
X-10 gives Y-10 - wrong
Y+10 gives X-10 - wrong
Y-10 gives X+10 - wrongP0 S0, P1 S0, P3 S0, and P4 S0
X+10 gives X+10 -OK
X-10 gives X-10 - OK
Y+10 gives Y-10 -wrong
Y-10 gives Y+10 - wrongP0 S1, P1 S1, P3 S1 and P4 S1
X+10 gives X-10 -wrong
X-10 gives X+10 - wrong
Y+10 gives Y+10 - OK
Y-10 gives Y-10 - OKP0 S0, P1 S1, P3 S0 and P4 S1
X+10 gives Y-10 - wrong
X-10 gives Y+10 - wrong
Y+10 gives X+10 - wrong
Y-10 gives X-10 - wrong.That's all the possible combinations.
Hi Ian,
Please do the individual X and Y motor tests (G1 S2 commands) described at https://duet3d.com/wiki/Configuring_RepRapFirmware_for_a_CoreXY_printer#Movement_section. I may have been wrong about swapping the X and Y motors, it may be that you just needed to reverse the direction of the Y motor,
HTH David
-
Hi David,
Yes it's looking like we don't need swap the wires. With them swapped from their original position when I do G91 then G1 S2 X10 F3000 I get +X -Y (plus X minus Y) movement. G1 S2 Y10 F3000 gives me -X -Y (minus X and Y).
I'll swap the wires back to their original positions and play around with motor directions again.
Ian
-
Yes that's fixed it. Wiring back to how it was. P0 and P3 set to S0 which is original. P1 and P4 set to S0 instead of the original S1 and now all movement in X and Y is as expected. Thank God I'm not actually losing my mind which is the conclusion that I was rapidly heading towards
So in summary, wiring needs to stay the same but Y motor direction needs to be reversed.
Wonder why no one else has picked up on this?
-
Thanks Ian, I'll correct the release notes. The reason I thought they needed to be swapped is because so many CoreXY users reported mirrored axes, which made me think it was caused by RRF not following the standard convention. Now I know that is wasn't.
-
Next problem. What's happened with G30? That's how I've always homed my Z axis - don't do any sort of flatness or level compensation. So my home Z is simply move up 5mm, move the centre of the bed, heat the hot end slightly to 140 to soften any blobs, then do G30, move back up 5mm and turn off the heater. Now when I try it, crazy things happen and it's all to do with G30.
So if I home X and Y, move the head to the centre of the bed then do G30, X and Y travel towards zero (but don't stop when they hit a switch, and Z simultaneously moves down (negative) seemingly forever but I have top hit emergency stop.
Edit. Oh and after an emergency stop, DWC asks to reset the firmware, I say yes, but the machine remains halted and I have to cycle the power to clear it.
