Posts made by RentableSocks

@phaedrux I'm already at 50% overlap and it still hasn't been fixed, so I'll be looking at my hardware I think.

@mrehorstdmd Nope, all lines except for where it starts and stops extrusion are equally spaced, at least by my eye.

The start and ends are misaligned though, but instead of with the long direction of each line, they're misaligned width wise. so like this ////// / instead of |||||l

All my belts and pulleys are tight so I'm gonna have a tough time finding any backlash.

Do you think a busted bearing could cause this behavior?

Been using my duetwifi based corexy for quite some time now, and I've just noticed that in some instances, the infill does not like to connect to walls. This seems like a motion planning thing to me, since I can't feel any backlash in the belts. The problem also only propagates in the same directions every time, it does not change like it should if there were backlash.

I've uploaded an image that shows the issue.

In the image, the long arms are along X and Y axes, and the short flats are on 45 degrees. The short sides that are on the top and the right side are the ones that have no connection between infill and perimeter, while the other sides seem properly connected.

any ideas?

@dc42
I think it would be good to cancel the print if G29 or G32 fails, since they're important for some setups. Maybe any code that involves homing shouldn't be allowed to continue printing if it fails, but I'm not sure if that would be good for everyone. If G29 and G32 cancelled an SD print upon failure, i think it would be a good stopgap before conditional gcode comes.

I like the idea of a parameter to change the behavior too, but conditional gcode is probably a better solution anyway and if it's a lot of work it probably won't be worth it.

It could be that something could also be done to retry G32 in a different way after a failure of a certain type. For instance if the probe was already triggered on one corner, then move that side up by a couple mm and retry, but that could be done with conditional gcode probably. Also it might be a bit dangerous to do that since the machine could possibly rip itself apart, but w/e.

My machine has 4 independent Z axis motors, so I use G32 to level the gantry before it starts printing. However, if G32 fails (due to too much gantry misalignment), the duet gives a message that it failed, but print continues without attempting to level the gantry.

Is there a way to cancel printing after a G32 failure so it doesn't ruin my bed surface again?

@phaedrux Right, but even with the SD card formatted properly, using one network vs the other still reduces the speed to sub 50KiB/s so I think that's the primary cause.

using the SD formatter on its own didn't work for me. I think my issue is a network issue because of my comcast router. My network tests were done with 64k block size so that could be helping, but I'm certain it's not the only thing at play here.

OK So I've just done some testing with using another router and different configurations.

I can't get rid of the original router, but I can connect up the second router as a repeater. I can connect the Duetwifi to the repeater network, and connect my laptop to the repeater network, and uploads work FAST (up to 600 KiB/s!!)(but something about comcast business class blocks DNS queries from repeaters so I don't get internet).

I can connect my laptop up to the comcast router, and keep the duetwifion the repeater network, but it seems that doing that brings the upload speed back down. There is some interaction from uploading through the comcast router.

I just tested a microSD card from microcenter, still very slow. I'm not sure what's going on here, but it's weird. Different router is my next step.

@phaedrux
I've got an extra router at home that I can bring in. I'll try that.

Thanks.

@phaedrux
Thanks for the formatting tip. I had just left the cluster size small so that could be a factor. I will retest with 64kb cluster size.

Traffic on the router is very low, and I have LOS with the router, maybe 15 feet away so signal strength is acceptable.

I've found out that I can't change any settings on the router as my internet provider has locked it down. There are few people in my area though, so I don't think there's much interference to deal with anyway. I might check with wifi analyzer later and see if some channels are clogged.

@dc42
OK so I've just tried another microSD card, and it is still slow. The drive is formatted in FAT32, which I think is the right format. Both of the microSD cards are small (4GB) so I can try using a 128 GB if you think that'll help. I can use a tool to format it for FAT32.

It seems my network is also pretty slow, are there values that need to be changed in the router?

New M122 values with the new SD card:

SD card longest block write time: 425.3ms, max retries 0

=== Network ===
Slowest loop: 426.79ms; fastest: 0.01ms

@dc42 said in Slow Upload, high Pending?:

But please confirm that you are uploading to the micro SD card in the socket on the Duet, not to an SD card in PanelDue or other external SD card socket.

Correct. I have no SD card in the PanelDue, just the one on the Duet. I'll try a different SD card and see if it helps.

Thanks.

@phaedrux said in Slow Upload, high Pending?:

Do you have another SD card to test?

Yes, I'll have to find a microSD to SD adapter though. MicroSDs are so hard to work with.

@dc42 said in Slow Upload, high Pending?:

2.02RC2

OK so I've tried 2.02RC2, and it didn't improve the speed, however the "pending" message count is now 0, so that's some type of improvement.

Network slowest loop has increased significantly, even though the signal strength has stayed the same.

Longest block write time seems slow to me, but I have no real comparison.

SD card longest block write time: 112.5ms, max retries 0

Here's the whole new M122 dump just after uploading a file (with 2.02RC2).

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02RC2(RTOS) running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-9T6BU-FG3S0-7J9FD-3S86Q-1B5VF
Used output buffers: 3 of 20 (13 max)
=== RTOS ===
Static ram: 28460
Dynamic ram: 98312 of which 0 recycled
Exception stack ram used: 328
Never used ram: 3972
Tasks: NETWORK(ready,400) HEAT(blocked,1232) MAIN(running,3540)
Owned mutexes:
=== Platform ===
Last reset 00:02:55 ago, cause: software
Last software reset at 2018-09-11 12:45, reason: User, spinning module GCodes, available RAM 6312 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0xffffffff
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 112.5ms, max retries 0
MCU temperature: min 31.4, current 31.6, max 32.0
Supply voltage: min 24.2, current 24.3, max 24.4, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
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
Expansion motor(s) stall indication: yes
Date/time: 2018-09-11 13:05:10
Slowest loop: 73.59ms; fastest: 0.07ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
Stack records: 1 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 idle 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: 114.32ms; fastest: 0.01ms
Responder states: HTTP(2) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8

• WiFi -
  Network state is running
  WiFi module is connected to access point
  Failed messages: pending 0, notready 0, noresp 0
  WiFi firmware version 1.21
  WiFi MAC address 84:f3:eb:83:48:7a
  WiFi Vcc 3.44, reset reason Turned on by main processor
  WiFi flash size 4194304, free heap 13552
  WiFi IP address 10.1.10.176
  WiFi signal strength -49dBm, reconnections 0, sleep mode modem
  Socket states: 4 4 0 0 0 0 0 0
  === Expansion ===
  DueX I2C errors 0

Okay I'll try one of those firmwares today and do an M122 after upload.

By pending, I mean under the wifi heading it says

"Failed messages: pending 841, notready 0, noresp 0"

I haven't found another M122 dump that showed pending messages.

I've been trying to figure out why uploading to the Duet is only achieving ~50kiB/s. Sometimes it starts out at ~100 then drops down to 50 in a couple seconds. I've also noticed that there's always a large number of "Pending" messages, even if I've just reset the board. My signal strength is good (-47dBm) and my slowest loop is 3.61ms. Any help is appreciated.

Here's my M122:
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS) running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-9T6BU-FG3S0-7J9FD-3S86Q-1B5VF
Used output buffers: 3 of 20 (20 max)
=== RTOS ===
Static ram: 28380
Dynamic ram: 95820 of which 16 recycled
Exception stack ram used: 332
Never used ram: 6524
Task NETWORK ready, free stack 324
Task HEAT blocked, free stack 1256
Task MAIN running, free stack 3560
=== Platform ===
Last reset 00:07:37 ago, cause: software
Last software reset time unknown, reason: User, spinning module GCodes, available RAM 6336 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0041f000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 20
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 32.6, current 32.8, max 33.1
Supply voltage: min 24.2, current 24.4, max 24.4, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
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
Expansion motor(s) stall indication: yes
Date/time: 2018-09-10 14:23:40
Slowest loop: 173.24ms; fastest: 0.08ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
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.0
Heater 1 is on, I-accum = 0.6
=== GCodes ===
Segments left: 0
Stack records: 1 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 idle in state(s) 14
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: 3.61ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8

• WiFi -
  Network state is running
  WiFi module is connected to access point
  Failed messages: pending 841, notready 0, noresp 0
  WiFi firmware version 1.21
  WiFi MAC address 84:f3:eb:83:48:7a
  WiFi Vcc 3.44, reset reason Turned on by main processor
  WiFi flash size 4194304, free heap 15208
  WiFi IP address 10.1.10.176
  WiFi signal strength -47dBm, reconnections 0, sleep mode modem
  Socket states: 0 0 0 0 0 0 0 0
  === Expansion ===
  DueX I2C errors 0

I found D2, and it has failed short, I think. I haven't removed it from the board though, so it could be shorted elsewhere.

Thanks for the information. I looked for D2 but I couldn't find it, there's a lot of stuff going on around that regulator. Is it worth me tracking it down or should I go for warranty?

If D2 caused the buck failure, would it damage the deux5 or paneldue? Also if U3 failed for a different reason, would it damage the deux5 or paneldue? I'm hoping only the main board is damaged.

The board was purchased maybe a month ago, by someone who is moving tomorrow. This might complicate the warranty stuff if I go that route.