New experimental firmware 1.19beta11
-
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
-
Thanks, I'll see if I can reproduce that.
-
So after updating to this firmware, my board as become completely unresponsive over night. initially it worked, but the web server kept crashing, as of this morning, the board, can not connect via wifi, or pointerface. As well as after to trying to attempt the Fallback procedure #3 I cant get the board to connect to SAM-BA.
I already followed the directions to a T
-
Does the Bossa Port appear in Device Manager after you press Erase for one second, then release it and press Reset?
Windows has a habit of disabling USB ports, so if it doesn't appear, try a different USB port or reboot Windows.
HTH David
-
Got it seems like I needed a different cable.
-
I installed 1.19 beta 11….I have something weird happening when I do a home all.....the x axis goes by the end stop switch and the x axis stalls....this does not always happen.....when I do a home on just the x axis there seems to be no problem.....the home all script I use is just calling the homex.g homey.g and homez.g files...so this shouldn't be a problem...maybe a bit of a bug
-
Read the upgrade notes, in particular the bit about deployprobe.g and retractprobe.g files.
-
new issue is with the duet not being able to find the its own access point. Though the board communicates with with my PC, and even confirms connectivity. I have no way of accessing the web server. This all worked perfectly while running firmware 1.17e
Now even after reverting back too my old firmware the duet wont seem to want to connect to the web server. Every time i look into my list of available networks the DuetWifi network shows even after ive already went through the set up. And it will keep showing the DuetWfif network as open no matter how many times i connect it to my internet network.
-
I do use a deployable bed probe so I require the two files….it is a Cartesian printer so this should not be an issue.
