New experimental firmware 1.19beta11
-
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.
-
Read the upgrade notes for beta 10.
-
Yes, found it. Deleted deploy probe and retract probe files and that has fixed it. Too much happening at once what with my fairly major machine upgrades as well as trying to keep abreast of all the firmware changes. Starting to feel my age….........
-
I get alot of ajax timeout errors. Feels like its every other minute…
To get it to work again I have to M552 S0 and M552 S1
Browser console:/rr_download?name=0:/sys/oem.json Failed to load resource: the server responded with a status of 404 (not found) /rr_download?name=0:/sys/oem.json Failed to load resource: the server responded with a status of 404 (not found) /rr_status?type=2 Failed to load resource: net::ERR_CONNECTION_TIMED_OUT /rr_download?name=0:/sys/oem.json Failed to load resource: the server responded with a status of 404 (not found) /rr_download?name=0:/sys/oem.json Failed to load resource: the server responded with a status of 404 (not found) /rr_download?name=0:/sys/oem.json Failed to load resource: the server responded with a status of 404 (not found) /rr_status?type=3 Failed to load resource: net::ERR_ADDRESS_INVALID /rr_connect?password=xxxxx&time=2017-7-29T14%3A55%3A56 Failed to load resource: net::ERR_INTERNET_DISCONNECTED /rr_download?name=0:/sys/oem.json Failed to load resource: the server responded with a status of 404 (not found) /rr_download?name=0:/sys/oem.json Failed to load resource: the server responded with a status of 404 (not found) /rr_status?type=1 Failed to load resource: net::ERR_CONNECTION_TIMED_OUT /rr_download?name=0:/sys/oem.json Failed to load resource: the server responded with a status of 404 (not found) /rr_connect?password=xxxxx&time=2017-7-29T15%3A37%3A45 Failed to load resource: net::ERR_ADDRESS_UNREACHABLE /rr_download?name=0:/sys/oem.json Failed to load resource: the server responded with a status of 404 (not found) /rr_download?name=0:/sys/oem.json Failed to load resource: the server responded with a status of 404 (not found) /rr_status?type=2 Failed to load resource: net::ERR_CONNECTION_TIMED_OUT /rr_download?name=0:/sys/oem.json Failed to load resource: the server responded with a status of 404 (not found) /rr_download?name=0:/sys/oem.json Failed to load resource: the server responded with a status of 404 (not found) -
The 404 error trying to load oem.json is normal, but the other errors are not. If the wifi module disconnects from the access point then it should try to reconnect automatically, so DWC should be able to reconnect after 20 seconds or so without having to use M552. I'll test the auto reconnect functionality in WiFiServer beta 10.
Have you tried increasing the number of retries configured in DWC? The default is 1.
-
Retry count was 1, I increased it to 2. Doubt it will help. the duet stops responding to ping and will not start responding in the 20 sec you stated. I get nothing on the panel duo console until I do the M552 S0.
Pinging every second when getting ajax timeout:
64 bytes from 192.168.1.167: icmp_seq=673 ttl=128 time=2.905 ms 64 bytes from 192.168.1.167: icmp_seq=674 ttl=128 time=2.662 ms 64 bytes from 192.168.1.167: icmp_seq=675 ttl=128 time=6.049 ms 64 bytes from 192.168.1.167: icmp_seq=676 ttl=128 time=2.209 ms 64 bytes from 192.168.1.167: icmp_seq=677 ttl=128 time=2.081 ms 64 bytes from 192.168.1.167: icmp_seq=678 ttl=128 time=3.954 ms 64 bytes from 192.168.1.167: icmp_seq=679 ttl=128 time=2.033 ms Request timeout for icmp_seq 680 Request timeout for icmp_seq 681 Request timeout for icmp_seq 682 Request timeout for icmp_seq 683 Request timeout for icmp_seq 684 Request timeout for icmp_seq 685 Request timeout for icmp_seq 686 Request timeout for icmp_seq 687 Request timeout for icmp_seq 688 Request timeout for icmp_seq 689 ... Request timeout for icmp_seq 815 Request timeout for icmp_seq 816 Request timeout for icmp_seq 817 Request timeout for icmp_seq 818 Request timeout for icmp_seq 819 ... Request timeout for icmp_seq 857 Request timeout for icmp_seq 858 Request timeout for icmp_seq 859 Request timeout for icmp_seq 860 Request timeout for icmp_seq 861 Request timeout for icmp_seq 862 ping: sendto: No route to host Request timeout for icmp_seq 863 ping: sendto: Host is down Request timeout for icmp_seq 864 ping: sendto: Host is down Request timeout for icmp_seq 865 ping: sendto: Host is down Request timeout for icmp_seq 866 ping: sendto: Host is down Request timeout for icmp_seq 867 ping: sendto: Host is down Request timeout for icmp_seq 868 ping: sendto: Host is down Request timeout for icmp_seq 869 ... ping: sendto: Host is down Request timeout for icmp_seq 1829 ping: sendto: Host is down Request timeout for icmp_seq 1830 -
Hello david,
Today I have free time I have tried the emergency stop again. It seems to only affect when doing a G29. If an emergency stop is made while running a G29, the printer stops and the firmware restarts, but it is still in the "HALTED" state and the power must be removed to restore its state.
I repeat, it just seems to happen if an emergency stop is made while running a G29
a greeting
