PanelDue 7i Error
-
Give the wires a though check. See if you can raise the error by wiggling the wire or sighly tugging on he connectors. If thats fine are you running shielded stepper wires and earth bonded stepper motors? Might be time to start considering extra electrical noise control.
-
Thanks for something to test.
Still trying to figure this out. -
Are you running the PanelDue at the default 57600 baud rate?
-
Yes, that was default and I haven't changed any setting. I tried upgrading it to the lastest version, and that didn't help.
-
-
-
And I have noticed that when the error occurs, the screen is no longer updating.
I tried to move both ends of the LCD wire and the error doesn't occur.
I have yet to put the proper ends on the LCD wire to plug into the DuetEth board as I just got it. Wire is snug and not loose to be the cable unless it came with a bad crimp. I can't tell if it's bad very easily by looking at the wire. It looks OK.Thanks!
-
It sounds like it may be caused by a bad crimp. Does this occur when the machine is idle, or only during a print?
-
That's a good question, had to look...
It appears only when it's printing. See below picture.
It happened every 30min or earlier until the print completed. And then so far not once in the last 4.5+ hours.
-
Spoke too soon. I am getting ready to print, going through screens, ran my default temp macro and then mesh bed level macro. Hit the stop button to check out the instant Stop feature you added and very happy with that by the way.... And check temps, everything stopped. Then got the pop up error. Not printing.
-
Does the PanelDue cable run very close to any heater or stepper motor cables?
-
I use the bed heater wire off of the Duet2 as signal wires, and not the load wires (which come off of the power supply/SSR. And the signal wires were running past the LCD wires. I just moved them as a test, and now they do run past a stepper motor, but there is aluminum extrusion and a metal plate (steel?) corner bracket, that may block any emi from the motor to effect the LCD wires...
-
@bluedust said in PanelDue 7i Error:
I use the bed heater wire off of the Duet2 as signal wires, and not the load wires (which come off of the power supply/SSR.
What does that mean?
By the way, Duet PWMs the NEGATIVE wire on both fans and the bed...
-
Sorry. I am using a SSR connected to my power supply. The actual AMPs/Power for the bed, isn't going through the wires coming off the of Duet2 and wouldn't put off as much EMI.
I moved the LCD wire about 4 or 5 inches away from the Stepper Motor and if I need to move it further, will need to do something extra/temporarily just to prove out interference. Let me know if I should.
I was away from the printer for while, and came back to see this new error message:
Error: Bad Command: S0 R476Thanks for the help!
-
I am not sure what to do about this error, but looking over the wires, they don't appear to be close enough to anything now to be affected by any sort of EMI, but I did notice the closest thing is the left side of the LCD it self. The left side of the LCD is about 3.5/4 inches away from a stepper motor. How close/far away should it be, to not be an issue (guaranteed a non issue)?
I still notice that if I am trying to use the LCD when it occurs, I have 2 or 3 seconds of the LCD not working, but as I don't alway see the issue happen live, and doesn't last long, it's hard to test it. It may just be that the screen doesn't update, but the GUI could still be maneuverable, and the pop up makes it difficult to test quick enough, before its cleared, and then the screen it updating properly again... But there does seem to be some kind of communication issue for a few moments and the Duet2 board doesn't seem to notice - a good thing.
Also, is there a way to view the current end stop status on the LCD?
What about the XYZ, locations?
The web interface seems to be updating live, all the time, and the LCD doesn't. It seems to not update during macros or what appears to be multi step operations. (example, the temp doesn't update live) Does it only update between each move?As always Thanks for the help!
-
@bluedust said in PanelDue 7i Error:
I am not sure what to do about this error, but looking over the wires, they don't appear to be close enough to anything now to be affected by any sort of EMI, but I did notice the closest thing is the left side of the LCD it self. The left side of the LCD is about 3.5/4 inches away from a stepper motor. How close/far away should it be, to not be an issue (guaranteed a non issue)?
That distance from a stepper motor should be sufficient.
I still notice that if I am trying to use the LCD when it occurs, I have 2 or 3 seconds of the LCD not working, but as I don't alway see the issue happen live, and doesn't last long, it's hard to test it.
That's expected. The Duet didn't process the request because of the checksum error, so the PanelDue didn't get a reply to that request.
Also, is there a way to view the current end stop status on the LCD?
Send M119 from the Console page.
What about the XYZ, locations?
The locations are shown on the Control page; or send M114 from the Console page.
The web interface seems to be updating live, all the time, and the LCD doesn't. It seems to not update during macros or what appears to be multi step operations. (example, the temp doesn't update live) Does it only update between each move?
The LCD won't update while a macro or other long operation that was commanded from the LCD is still in progress.
Which firmware version are yo running on the Duet?
-
I just wish I had another way to test this to confirm if it was the screen, or wire.... Is there anything on the PanelDue 7i I could look at? Like a loose wire? or anything else that could cause this issue? I was assuming it would either work, or not. And not be a random thing if it was something I could obviously see as a problem. I did give it a once over to confirm everything was plugged in before I power it up the first time. I think I even took pictures, as I was trying to figure out what version I had before I updated it. This was before I found out the 7i, was automatically 1.4... Let me know if you would like to see the pictures. You would know more about what to look for then I would.
Thanks!
-
I didn't think about this before, but as it just occurred again,... could the PanelDue errors be related to the Website disconnection errors I am also seeing?
Most of the time, the website comes back within seconds, but randomly, the page won't auto reload, and I have to try it again a few times, and wait what can seem like minutes later.
It never stops printing so I wasn't really thinking about it. Also, I think this started happening after one of the RC upgrades, but I didn't try all of them. Had other issues, that was resolved in RC5.
I have a DuetEth board, plugged into a Gigabit Business class switch. My computer is also a Desktop PC plugged into the same switch. (I am mentioning this as I am not using a wireless network for the Duet2)
Adding Diagnostics below incase you find it helpful.
As always, I appreciate your help!
10:38:27 AM
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02RC6(RTOS) running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DGM-9T6BU-FG3S0-7JTDL-3SN6N-TS6VG
Used output buffers: 3 of 20 (16 max)
=== RTOS ===
Static ram: 25524
Dynamic ram: 98332 of which 0 recycled
Exception stack ram used: 592
Never used ram: 6624
Tasks: NETWORK(ready,560) HEAT(blocked,1232) MAIN(running,3804) IDLE(ready,200)
Owned mutexes:
=== Platform ===
Last reset 15:27:33 ago, cause: power up
Last software reset at 2018-12-18 18:29, reason: User, spinning module GCodes, available RAM 6940 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 24
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 435.5ms, max retries 0
MCU temperature: min 19.8, current 32.2, max 32.4
Supply voltage: min 19.9, current 23.8, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: ok, SG min/max 141/663
Driver 1: standstill, SG min/max 179/516
Driver 2: ok, SG min/max 0/1023
Driver 3: ok, SG min/max 0/1023
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2018-12-19 10:38:17
Cache data hit count 4294967295
Slowest loop: 226.93ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0
=== Move ===
Hiccups: 475550, StepErrors: 0, LaErrors: 0, FreeDm: 153, MinFreeDm: 120, MaxWait: 15606616ms, Underruns: 0, 2
Scheduled moves: 243547, completed moves: 243518
Bed compensation in use: mesh
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.3
Heater 1 is on, I-accum = 0.9
=== GCodes ===
Segments left: 1
Stack records: 2 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is doing "G1 X142.800 Y85.138 E0.1111" in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 436.04ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplex -
The only things that worry me in that report is that the "Slowest loop" times for both Main and Network are much longer than usual. This could be because you uploaded a large file and your SD card has become slow at writing.
-
Sometimes I upload files while it's printing and notice it uploads slower then normal. Also, some times it starts out so, and finishes fast and lately, it retries the upload on it's own. Had been doing that for the past month. Used to error out and I would have to retry it manually (was rare). Now that it automatically a retries, it happens much more often, sometimes retries 3 times before it works.
When I say fast upload speeds, I mean over 700kps. I haven't seen it do it that fast lately, but have been uploading the next gcode while printing as mentioned, more recently....
If it uploaded less then 450kps I consider that slow. I will keep better track and see if it consistently slow, med or fast when it's not printing when I upload.Oh and...
I am not uploading when I see the errors.Thanks!
