New experimental firmware 1.19beta11
-
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.
-
every time i try to connect my duet too my network, instead of getting an Ip address i get this
READ: DuetWiFiServer version 1.03 (ch fork)
READ: Flash size 4194304, free RAM 30544 bytes, WiFi Vcc 3.16V, host name: duetwifi, reset reason: Turned on by main processor
READ: WiFi is running as an access point with name DuetWiFiI still then have an access point for the Duet available to connect too, even after performing the procedure over multiple times times
-
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
Did you do a simultaneous upgrade of the main and the WiFi firmware as described at https://duet3d.com/wiki/DuetWiFiFirmware_1.19beta ?
-
I just setup my delta with a new DuetWifi I just purchased and it has been a struggle.
I kept having JSON errors and was unable to use the web server, consistently it would switch from being in AP mode and back to being associated with my AP depending on it's mood when I would restart.
So I upgraded to 1.19beta11 following the instructions in the document. I used M997 S0:1 to do the upgrade of both firmwares.
So now it crashes with JSON shortly after opening the web page.
"× Communication Error
An AJAX error has been reported, so the current session has been terminated.
Please check if your printer is still on and try to connect again.
Error reason: SyntaxError: Unexpected token a in JSON at position 65"
So I put it back to 1.18.1 and had the same issues. I erased the firmware and reloaded using the SAM-BA tool and I upgraded to the beta again and I still have the same problems.
This is disappointing.
Firmware Name: RepRapFirmware for Duet WiFi
Firmware Electronics: Duet WiFi 1.0
Firmware Version: 1.19beta11 (2017-07-25)
Web Interface Version: 1.17+2
Web Interface by Christian HammacherNo matter what I have done has not worked as of yet.
Please help I ordered your system because it looked to be the best integrated most complete…....
