we really need more information than “it hangs” does it crash? does it just stop? are there messages telling you why it stopped? FWIW I run this everyday and have zero problems!
and FWIW there have been NO changes to the code since master that would affect G32.
No problem, I am not trying to provide anything other than what you need to investigate the problem further. So here are some more data points:
-
it’s a new smoothie build, so I am not saying there is anything wrong with edge vs. an older build.
-
I don’t want to say crash or hang because I am not really sure what’s going on and I don’t want to give the wrong impression
3 the machine is reasonably well built given the physical limits of the Rostock mini pro design (not as rigid as a Kossel etc.)
When running the command, when the “issue” occurs, The effector will stop moving. The mini viki 2 display does not show any odd symptoms, it says “Smoothie Printing” as usual. The log stops getting ok’s status messages etc. then windows, will lose the USB smoothieboard device and try to reaquire it. It will come up as device not recognized after a bit. Heaters fans etc seem to stay on.
Only resetting the controller returns things to normal. Then windows recognizes the device again… no driver remove/reinstall just the typical events you would see when you plug in any smoothieboard or compatible.
The measurements of the arms bed and radius are very good if not excellent. And the physical adjustments of the endstops are the same. When the cal is successful, and it has been under some circumstances, the suggested soft trim “set trim to X:0.000000 Y:-0.066913 Z:-0.059882” that seems to be not a lot to me, but I could be wrong.
It may have something to do with the numbers I am choosing for the leveling strategy.
I chose 7 as a starting level, because for some odd reason 10 wasn’t working, kicking off the error that I needed to check my starting values for the leveling strategy ( I know I am paraphrasing the error code here, sorry, I can dig into the older logs if I need to be more precise).
I chose a radius for calibration of 60 because I didn’t want to run into bed retention with the heater block. The actual glass plate is the typical 170mm radius/85mm diameter
The probe points tap dead center in the FSR’s, I can see them through the bed.
I am probing at pretty slow speeds, the Rostock design as stated above is less rigid, as stated above, if the frame flexes too much dur to inertia and slamming the effector around, FSR’s under the bed will give off a bunch of pre-mature positives, (technically not false ones, the sensors are being triggered by the plates inertia relative to the frame or by the frame flexing against the plate squeezing the FSR)
The JhonSL fsr controller further minimizes false readings, by actively compensating for bed weight, print weight etc. only a tap or other sudden change really sets off the output of the fsr controller board to the Azteeg probe pin.
I know you and are aware of most of this if not all, I am just trying to provide the details for someone who’s doesent that may read this later and be in a similar situation.
Since delta radius is really just a number that controls where the Kinematics and inverse Kinematics are equal as I understand delta math, I try not to get too hung up on measurements that are NASA accurate. I did for a long, time and couldn’t wrap my head around why the most precisely measured and built delta didn’t just simply need no calibrating out of the gate. I know the results of what the tramming system reports are more important than falling in love with your precisely measured actual radius. Flat math within your build envelope is what you are shooting for regardless of what you “know” delta physical measurement are.
I don’t yet have data on what the controller play leds are doing when the issue occurs.
Here is a log of the Successful G32 E0|M500|G32 R0|M500 (Success) followed by the G32 fail, from the terminal perspective, it’s not very informative to me, but you might see a clue and let my know of anything else I could try.
To be clear, I think smoothie is a great project. I am committed to converting everything I can to smoothieware, just puzzled by this one and wondered if I am doing it wrong or missed something obvious.
Connecting…
Printer is now online.
G32 E0
SENDING:G32 E0
Calibrating Endstops: target 0.030000mm, radius 60.000000mm
set trim to X:0.000000 Y:0.000000 Z:0.000000
initial Bed ht is 165.367523 mm
center probe: 0.0081
T1-0 Z:7.1100
T2-0 Z:7.1634
T3-0 Z:7.1578
set trim to X:0.000000 Y:-0.066913 Z:-0.059882
T1-1 Z:7.1578
T2-1 Z:7.1831
T3-1 Z:7.1662
trim set to within required parameters: delta 0.025299
Calibration complete, save settings with M500
M500
SENDING:M500
Settings Stored to /sd/config-override
G28
SENDING:G28
G32 R0
SENDING:G32 R0
Calibrating delta radius: target 0.030000, radius 60.000000
initial Bed ht is 165.353455 mm
center probe: -0.0284
CT Z:7.014
T1-1 Z:7.177
T2-1 Z:7.132
T3-1 Z:7.172
C-1 Z-ave:7.1606 delta: -0.146
Setting delta radius to: 85.2844
T1-2 Z:7.045
T2-2 Z:7.065
T3-2 Z:7.096
C-2 Z-ave:7.0688 delta: -0.054
Setting delta radius to: 85.1484
T1-3 Z:7.009
T2-3 Z:6.989
T3-3 Z:7.054
C-3 Z-ave:7.0172 delta: -0.003
Calibration complete, save settings with M500
M500
SENDING:M500
Settings Stored to /sd/config-override
G28
SENDING:G28
G32
SENDING:G32
Calibrating Endstops: target 0.030000mm, radius 60.000000mm
set trim to X:0.000000 Y:0.000000 Z:0.000000
initial Bed ht is 165.519394 mm
center probe: 0.0194
T1-0 Z:6.8428
T2-0 Z:6.9075
T3-0 Z:6.9187
set trim to X:0.000000 Y:-0.080995 Z:-0.095077
T1-1 Z:6.8653
T2-1 Z:6.9356
T3-1 Z:6.9159
set trim to X:0.000000 Y:-0.169040 Z:-0.158474
T1-2 Z:6.9272
T2-2 Z:6.8822
T3-2 Z:6.8625
set trim to X:-0.080995 Y:-0.193688 Z:-0.158474
T1-3 Z:6.8372
T2-3 Z:6.9019
T3-3 Z:6.9272
set trim to X:-0.080995 Y:-0.274683 Z:-0.271186
T1-4 Z:6.8794
T2-4 Z:6.8484
T3-4 Z:6.8766
set trim to X:-0.119725 Y:-0.274683 Z:-0.306401
T1-5 Z:6.9075
T2-5 Z:6.8541
T3-5 Z:6.8850
set trim to X:-0.186638 Y:-0.274683 Z:-0.345150
T1-6 Z:6.8597
T2-6 Z:6.8737
T3-6 Z:6.8766
trim set to within required parameters: delta 0.016876
Calibrating delta radius: target 0.030000, radius 60.000000
initial Bed ht is 165.516586 mm
center probe: -0.0059
CT Z:7.006
T1-1 Z:6.851
T2-1 Z:6.907
T3-1 Z:6.908
C-1 Z-ave:6.8887 delta: 0.117
Setting delta radius to: 85.4414
;ITS HANGING NOW
* Unknown syntax: ;ITS HANGING NOW
[ERROR] Can’t read from printer (disconnected?) (SerialException): call to ClearCommError failed
[ERROR] Can’t write to printer (disconnected?) (SerialException): WriteFile failed ([Error 22] The device does not recognize the command.)
what host are you using? the * Unknown syntax is very unusual and makes me think the host is disconnecting for some reason because of the feedback it is getting.
It seems smoothie is running fine and not crashing you are just getting a host disconnecting which is usually the hosts fault. but we need some more info.
Without seeing what smoothie error is being sent it is hard to diagnose. I suspect it is a premature FSR trigger.
IF you can run G32 from a plain terminal or from printerface, and paste the entire console log to http://pastebin.com and give us the link. I need to see what smoothie is reporting and not have the host disconnect
That was from pronterface. The unknown syntax error is from me typing “its crashing now” at the console when smoothie stopped.
I will see what I can come up with on the plain terminal side. I assume that telnet to a network interface will provide less data, not more correct? If that’s a better route than the USB serial, I can install a nic on the Azteeg if that’d help.
Also remember that it did the same thing from the custom menu panel command. I THINK we can eliminate the host as a cause.
I know you are just looking for anything that will keep reporting status messages.
Are there any debug or verbose commands I should set first?
Also I have been running the USB serial at 250000 I assume this is correct.
I haven’t seen anything in the config to set the baud rate on the USB side UART, only config for the hardware UART for the second serial port.
I can connect an Esp8266 there and Bluetooth in if that might provide a better chance of catching the error.
Again, just trying to take the route you would prefer, and I have the options on hand.
what we really need to know is if it crashed or not and for that you need to see the leds as asked before. Then to debug further you need to read how to provide a crashreport on the wiki, under troubleshooting, you will need an ftdi on the uart.
USB serial has no bauidrate it is ignored.
network will not work at all.
if it crashed then the crash dump is essential to go any further as I cannot duplicate this issue at all.
Oh and for what it’s worth, I miss the old 9-pin serial ports that didn’t disconnect, USB serial is great and convenient, but hardwareserial was better for diagnosing this kind of thing
there s h/w serial it is on the uart port. read about it on the iki.
do you have an aluminum or glass bed?
try the latest firmware-hires.bin on github in the Firmware folder. I reduced the stack usage for some operations and that may be what you are running into given how odd the failure mode is. It worked for someone else having G32 issues.
it is just the latest version
Performance of the level function seems much improved. It completes, the console still reports some semaphore errors. I posted the logs publicly to pastebin as you requested earlier. Username Mshievitz just like here.