PanelDue 7i Error
-
-
-
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!
-
I don't know if the errors are getting worse, or just more annoying as I seem to be using the LCD more often while they are occuring. A few times when I wanted the command to work instantly, I had to wait a ~5 seconds before I could try it again.
Is there anything I can do to better troubleshoot this issue?
In reading about the LCD before I bought it, it sounds like I can use the 10 pin cable for power and data for the LCD, and not just for MicroSD card data. Is this true? Do you think that would help this issue? 300mm cable length isn't very long, but think I could make it work without major reconfiguring just so I can test and see if that resolves the issue. If you think it could help, can you give me a link to a recommended cable?
Thanks!
-
I tried to run M122, and was disconnected from the printer. This used to never happen, and random disconnects are more frequent too. But I feel like its something diagnosable/easy fix, and not just trying to bliam the DuetEth.
I am only mentioning it right now, as I am curious if you think the PanelDue7i and this issue could be related.
Thanks!
-
Just successfully ran M122
=== Platform ===
Slowest loop: 123.09ms; fastest: 0.07ms
=== Network ===
Slowest loop: 203.26ms; fastest: 0.02ms -
Do you often get so many hiccups reported by M122?
