upgrade issue
-
How exactly do you have the BLTouch wired?
You said you used M558 P7 before and now switched to P9. Is the BLTouch connected to the Z endstop input? Using P9 requires it to be connected to the Z probe input.
-
To try and clear the Java script error load the DWC after a reboot, go to the settings page, click load factory defaults and restart.
-
Deployment and retraction of the probe is handled automatically by the firmware, so you should remove the M280 commands from your homing and bed probing files, leaving just the ones in deployprobe.g and retractprobe.g.
-
The probe is connected to probe pin. Servo driven off heater 7 on the expansion header breakout board.
Probe uses m280 p7 s10 deploy, m280 p7 s90 retract, m280 p7 s160 test/reset. the p7 in this code = h7 servo channel 7. m307 h7 a-1 c-1 d-1 command to use heater 7 as servo output.How than does the probe deploy if I remove the m280 commands?
I have power cycled the board and reloaded the DWC many times over 2 days. I tried reset factory default, apply setting as well. I get the java error every time I try. Not always right away, but within 5 minutes or so. I tried 1.21.1, 1.21.2, and 1.22. all 3 of these DWC versions throw this error. Probe is now back to non functioning altogether. Plus if I upload a print file duet waits for heaters and goes straight to print moves without homing. 28 command comes first than g29.1 after that. Printer just starts printing. The some axes are not homed indicator is present on DWC screen when this is going on.
I have an sd card with 1.19.1 firmware and 1.15 DWC loaded. I reloaded these versions back to board and everything works perfect. I only changed p9 back to p7 for probe. No java error, printer obeys homing command from slicer and probe works perfectly. I just wanted to stay current with my setup, but I guess things aren't ready yet for me to use the new stuff. Maybe when these version are more stable I might be able to figure them out.
-
I can't get past the java script error gcode is not a function. I erased all gcode from gcode folder and did a fresh install completely erasing board. I used programmer to burn boot loader and only installed the required files for version 2.01rtos firmware and web interface 1.22. Now I cannot get beyond this java script error. cycling power clears message. I restore factory and confirm applied values. Type anything in gcode window and java script gcode is not a function. I followed the " in the mean time instructions" to work around it, but failed. I'm not a quitter, but I know when I'm beat. I never thought you had to be a programmer to 3d print. This stuff is just beyond what the average person interested will be willing to deal with. I'm not sure why it has to be so manual and complicated to use. Owe well, thanks for your time, but this system has too many complications and reading over the many post it seems that there are too many issues wrong to enjoy using the printer and far too many hours trying to config, maintain it. I really thought this would be a fun thing for my family.
-
A JavaScript error has occurred so the web interface has closed the connection to your board. It is recommended to reload the web interface now. If this happens again, please contact the author and share this error message:
Version: 1.22
Message: TypeError: rememberedGCodes.indexOf is not a function
URL: http://192.168.1.50/js/dwc.js
Line: 1175:52
Error object: {}What does line 1175.52 indicate? I wiped everything from the entire system containing gcode files.
-
ok I down graded to dwc 1.21.1 and java error went away. Now the problem is hitting the home all or any single homing button throw an error G0/G1 axis not homed error. As if I'm trying to jog without homing, but I'm trying to home. What exactly is going on because every single function doesn't work. I'm being blocked around every corner here. I mean nothing is working no matter what version I use newer then 1.19.1 firm and 1.15 dwc those are the only ones that work with my 1.02 duet Ethernet board.
-
@sir-printsalot said in upgrade issue:
How than does the probe deploy if I remove the m280 commands?
The m280 commands will be in the deployprobe.g and retractprobe.g files. The system can then handle the deployement and retraction on it's own when using the P9 probe type for the BLTouch. You can manually call those macros with M401 and M402. This allows the system to keep track of the deployment state of the pin. This is only the case when using the P9 probe type which is dedicated to the BLTouch.
The some axes are not homed indicator is present on DWC screen when this is going on. G0/G1 axis not homed error.
This is due to a change made in 1.21 that prevents the movement of axis until they have been homed. It is intended to prevent unintentionally ramming the print head into a physical endstop.
From the release notes:
On Cartesian and CoreXY printers, normal G0 and G1 moves are no longer allowed before the corresponding axes have been homed. In particular, if your homex.g, homey.g and homeall.g files raise Z a little at the start and lower it at the end, you will need to add the S2 parameter to those G1 Z moves. Otherwise the G1 Z move will be refused unless Z has already been homed and the homing macro will be terminated. If you want to allow axis movement prior to homing, put M564 H0 in config.g.
The key part in your case is at the end. If you want to allow axis movement prior to homing, put M564 H0 in config.g. That will return it to the old expected behaviour.
Upgrading through so many versions at once can be tricky since so many things can change between releases. Sorry that caught you off guard.
https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md -
@sir-printsalot said in upgrade issue:
Owe well, thanks for your time, but this system has too many complications and reading over the many post it seems that there are too many issues wrong to enjoy using the printer and far too many hours trying to config, maintain it. I really thought this would be a fun thing for my family.
Sorry you got caught up in an upgrade headache. Please return if you'd like to give it another crack.
-
Why does it feel like I'm not the one giving up? Why does it feel like I am the only one that believes these issues are actually happening? I have provided every thing requested and responded fast to questions. If I had something to give back I would, but my knowledge is limited. Is there a place to pay for software that someone else configures? I think kindness take you so far than you gotta reach for the wallet. Who needs work because there is an answer somewhere?
-
Ok I missed the second to last reply you left. Sorry you explained the reason/function better as to the m280 m401 thing. Thank you for that. My last post sounded bad please forgive me. As to the movement before homing code that gets added, it's sure sounds a lot like a firmware lock. I can't home not even x or y. If it's to prevent movement before homing than that code needs not be over-ridden before a homing event takes place. I can't home without that code added. Added I can jog and crash. It seems like code added just to add more code to over-ride itself with no usable benefit. I can't do anything without, and crash end stops with it. I'm not even speaking of the probing issue. I removed z lift and tried y homing by itself and no go. I added the s2 to this homing command. Again no Go. I keep getting additional info and my hopes up together, but nothing will allow a single function to perform. This machine is so foreign to me now, I don't know it.
Has there ever been a firmware interface combo that didn't produce false error and actually allow basic height run prints? If so forget this new stuff I want basic printing with bed auto leveling.
now I'm stuck with it in erase no firmware on board. I did this earlier because firmware downgrade didn't reflect any change. Now I tried going back from 2.01 to 1.19.1 what I was using and bossa port programming is now longer responding.
-
@sir-printsalot said in upgrade issue:
If it's to prevent movement before homing than that code needs not be over-ridden before a homing event takes place.
Exactly. The preferred way to handle this is to add S2 to any non-homing moves in your homing files so that they are allowed. This usually applies to raising the head or lowering the bed a bit before homing X and Y. This method has the benefit that the jogging commands or through gcode won't be able to crash the head. This was the intention of the change at any rate. If you'd like to go this route, you can post your homing files and I can tell you what you need to change. Or you can use the following example to modify it yourself.
homeall.z G91 ; relative positioning G1 Z5 F200 S2 ; Lower bed 5mm to ensure it is below the switch trigger height, use S2 switch to allow movement without homing. ; Home XY for CoreXY ; G1 S1 X-375 Y305 F4000 ; course home X or Y Use S1 switch to seek endstop G1 S1 X-375 F4000 ; course home X G1 S1 Y305 F4000 ; course home Y G1 X5 Y-5 F1000 ; move away from the endstops G1 S1 X-10 F600 ; fine home X G1 S1 Y10 F600 ; fine home Y ; Z homing section for BLTouch follows ; G90 ; absolute positioning G1 X190 Y90 F6000 ; Move x and Y axis over to bed center G30 ; Probe again to get a more accurate positionAlternatively you can add M564 H0 to config.g to allow all moves without homing entirely. If you have added that and it still doesn't work, please send M564 in the console and report the reply.
-
Sorry, just to back up a bit, I am unclear on what state your board is currently in. Are you in a state where you can power on the board and reach the DWC?
