Closed anon65453 closed 1 year ago
What is your settings from $S
?
How are you connecting over WiFi in Lightburn, which protocol are you using?
I am seeing the same thing on 3.7.1, thru the UI , a single jog click is taking up to 30 seconds.
@lugeral what is the output from the jog command?
How are you connecting over WiFi in Lightburn, which protocol are you using?
Using the default IP connection in Lightburn. Add New Device, choose GRBL, then IP Connection, using static IP xxx.xxx.xxx.3
Framing a job in Lightburn over Wifi with Lucid 3.7.1 is causing the machine to make a lot of sounds and move in a terrible manner. It appears the webpage may be the issue. It sounds similar to another post I have mentioned. Using the same firmware but over USB results in much smoother operation. Also jobs don't fail!
Here is the contents of running $S
$S $Start/Message=Grbl \V [FluidNC \B (\R) \H] $Firmware/Build= $SD/FallbackCS=-1 $Report/Status=3 $Config/Filename=config.yaml $Message/Level=Warning $Notification/Type=NONE $Notification/T1= $Notification/T2= $Notification/TS= $Telnet/Enable=ON $Telnet/Port=23 $HTTP/BlockDuringMotion=ON $HTTP/Enable=ON $HTTP/Port=80 $WiFi/Mode=STA $Sta/SSID=Casa $Sta/Password=** $Sta/MinSecurity=WPA2-PSK $WiFi/FastScan=ON $Sta/IPMode=Static $Sta/IP=192.168.1.3 $Sta/Gateway=192.168.1.1 $Sta/Netmask=255.255.255.0 $AP/Country=US $AP/SSID=FluidNC $AP/Password=** $AP/IP=192.168.1.3 $AP/Channel=1 $Hostname=fluidnc ok
You can see here how slow the Wifi connection is compared to USB below.
This is operating over Wifi, you can see the belts shaking violently and how slow it is to frame the job. https://youtube.com/shorts/TymS4qBxlb0
This is operating directly over USB/Serial and appears to have much smoother movement. https://www.youtube.com/shorts/4KRMixaf-WA
Sorry my post was in error.
On Tue, 20 Jun 2023 at 20:55, anon65453 @.***> wrote:
How are you connecting over WiFi in Lightburn, which protocol are you using?
Using the default IP connection in Lightburn. Add New Device, choose GRBL, then IP Connection, using static IP xxx.xxx.xxx.3
Here is the contents of running $S
$S $Start/Message=Grbl \V [FluidNC \B (\R) \H] $Firmware/Build= $SD/FallbackCS=-1 $Report/Status=3 $Config/Filename=config.yaml $Message/Level=Warning $Notification/Type=NONE $Notification/T1= $Notification/T2= $Notification/TS= $Telnet/Enable=ON $Telnet/Port=23 $HTTP/BlockDuringMotion=ON $HTTP/Enable=ON $HTTP/Port=80 $WiFi/Mode=STA $Sta/SSID=Casa Raab VPN $Sta/Password=** $Sta/MinSecurity=WPA2-PSK $WiFi/FastScan=ON $Sta/IPMode=Static $Sta/IP=192.168.1.3 $Sta/Gateway=192.168.1.1 $Sta/Netmask=255.255.255.0 $AP/Country=US $AP/SSID=FluidNC $AP/Password=** $AP/IP=192.168.1.3 $AP/Channel=1 $Hostname=fluidnc ok
— Reply to this email directly, view it on GitHub https://github.com/bdring/FluidNC/issues/930#issuecomment-1599997235, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2NI34BXGHLREIW7LVL36HLXMJPBZANCNFSM6AAAAAAZNIDLRU . You are receiving this because you were mentioned.Message ID: @.***>
I gave Lightburn a try and generate dithered laser gcode from an image: circuit.txt
When running this file from LB over WiFi I notice that I get a couple of IDLE states. To me, this suggests that the FluidNC planner is starving. Your first video where you outline the work it makes an ellipse around the work. If this ellipse is done using small line segments it could mean that the controller is starving.
You have set the max speed to 10000 mm/min (166 mm/sec) and the acceleration to 1000 mm/sec2. Which means (if I did my calculations correct) it will reach the max speed (or stop from full speed) in 0.166 seconds.
So the horrible motion that you see in your first video is probably caused by a quite agressive acceleration setting together with a starving planner buffer. This would probably also make the machine to lose steps which could be the cause for distorted images.
The next question is why it is starving. By looking at my gcode it has ~3 gcode lines per mm with around 10 bytes per line which gives us ~30 bytes per mm. Your max rate is set to 10000mm/min, but let us run things a bit slower 6000mm/min => 100mm/sec. That would require the planner buffer to handle 30 * 100 = 3Kb/s.
I gave Lightburn a try and generate dithered laser gcode from an image: circuit.txt
When running this file from LB over WiFi I notice that I get a couple of IDLE states. To me, this suggests that the FluidNC planner is starving. Your first video where you outline the work it makes an ellipse around the work. If this ellipse is done using small line segments it could mean that the controller is starving.
You have set the max speed to 10000 mm/min (166 mm/sec) and the acceleration to 1000 mm/sec2. Which means (if I did my calculations correct) it will reach the max speed (or stop from full speed) in 0.166 seconds.
So the horrible motion that you see in your first video is probably caused by a quite agressive acceleration setting together with a starving planner buffer. This would probably also make the machine to lose steps which could be the cause for distorted images.
The next question is why it is starving. By looking at my gcode it has ~3 gcode lines per mm with around 10 bytes per line which gives us ~30 bytes per mm. Your max rate is set to 10000mm/min, but let us run things a bit slower 6000mm/min => 100mm/sec. That would require the planner buffer to handle 30 * 100 = 3Kb/s.
The only difference between the sloppy movements and the smooth is WiFi vs USB. I have left the acceleration and speeds the exact same. These figures came from the default settings from the laser firmware.
Closing the webpage helps or turning off 50ms grbl reporting over WiFi but is not enough to get a job to complete without error. Specifically it’s always the X axis that gets confused, not the Y axis. This is somewhat odd. Why only X?
I have many jobs complete over WiFi previously but now on 3.7.1 they all fail at a point due to X axis shifting.
Using USB has avoided this issue.
Ugh accidentally clicked the closed button. GitHub on mobile do not suggest.
It appears maybe something else is going on? My last job was interupted, due to panic.
Is this related to the wifi?
Layer Design Guru Meditation Error: Core 0 panic'ed (InstrFetchProhibited). Exception was unhandled. Core 0 register dump: PC : 0x00000000 PS : 0x00060030 A0 : 0x800f33d2 A1 : 0x3ffe7560 A2 : 0x3ffcb628 A3 : 0x3ffcb4d5 A4 : 0x00000000 A5 : 0x00000000 A6 : 0x3ffcab80 A7 : 0x00000000 A8 : 0x800f3270 A9 : 0x3ffe7540 A10 : 0x3ffee2a4 A11 : 0x3ffee2a4 A12 : 0x3ffbc170 A13 : 0x00000000 A14 : 0x00000000 A15 : 0x00060023 SAR : 0x0000001a EXCCAUSE: 0x00000014 EXCVADDR: 0x00000000 LBEG : 0x4008b6c4 LEND : 0x4008b6da LCOUNT : 0xffffffff Backtrace: 0xfffffffd:0x3ffe7560 0x400f33cf:0x3ffe7590 0x400f0707:0x3ffe75b0 ELF file SHA256: c0232e7857604a85 Rebooting... ets Jul 29 2019 12:21:46 rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff0030,len:1184 load:0x40078000,len:13220 ho 0 tail 12 room 4 load:0x40080400,len:3028 entry 0x400805e4 [MSG:ERR: Skipping configuration file due to panic] Grbl 3.7 [FluidNC v3.7.1 (wifi) '$' for help]
here are the last moves from the console
<Run|WPos:258.325,186.137,0.000|Bf:0,256|FS:3351,0|Ov:100,100,100|A:C> <Run|WPos:259.150,186.238,0.000|Bf:0,256|FS:6941,0> [GC:G1 G54 G17 G21 G91 G94 M4 M8 T0 F16000 S650] [GC:G1 G54 G17 G21 G91 G94 M4 M8 T0 F16000 S0] <Run|WPos:257.362,186.238,0.000|Bf:0,256|FS:9596,0> [GC:G1 G54 G17 G21 G91 G94 M4 M8 T0 F16000 S650] [GC:G1 G54 G17 G21 G91 G94 M4 M8 T0 F16000 S0] <Run|WPos:252.962,186.238,0.000|Bf:0,256|FS:12298,0> [GC:G1 G54 G17 G21 G91 G94 M4 M8 T0 F16000 S650] [GC:G1 G54 G17 G21 G91 G94 M4 M8 T0 F16000 S0] [GC:G1 G54 G17 G21 G91 G94 M4 M8 T0 F16000 S650] [GC:G1 G54 G17 G21 G91 G94 M4 M8 T0 F16000 S0] <Run|WPos:245.850,186.238,0.000|Bf:0,256|FS:15019,610> [GC:G1 G54 G17 G21 G91 G94 M4 M8 T0 F16000 S650] $Report/Interval=0 [GC:G1ok <Alarm|WPos:0.000,0.000,0.000|Bf:15,256|FS:0,0|WCO:0.000,0.000,0.000> <Alarm|WPos:0.000,0.000,0.000|Bf:15,256|FS:0,0|Ov:100,100,100> <Alarm|WPos:0.000,0.000,0.000|Bf:15,256|FS:0,0> <Alarm|WPos:0.000,0.000,0.000|Bf:15,256|FS:0,0> <Alarm|WPos:0.000,0.000,0.000|Bf:15,256|FS:0,0> <Alarm|WPos:0.000,0.000,0.000|Bf:15,256|FS:0,0> <Alarm|WPos:0.000,0.000,0.000|Bf:15,256|FS:0,0>
@anon65453
Please start your own problem issue, so we can see your setup
Originally posted by @bdring in https://github.com/bdring/FluidNC/issues/936#issuecomment-1613445306
@anon65453 Based on your sucessful report at #936, can we close this ticket?
@anon65453 Are you still having this problem?
All good here.
@anon65453 Are you still having this problem?
Yes it does still appear to be an issue, definitely not stable enough to use on wifi alone. I have been using both wifi and serial at same time. Serial in Lightburn to run the actual jobs but then Wifi to jog the head, monitoring, and error resolution.
I turned telnet back on, and configured over wifi again to test. Here is what I see.
Simple jog command takes 1 minute or more and WebUI is crashing after issuing the jog commnd. Appears to be worse than before. this issue was opened because I was streaming gcode too fast for wifi. [breiler] had mentioned the code was starving, will this always be the case?
After running a 5mm jog the webui crashes as well.
Are you running the latest prerelease firmware 3.7,2-pre3 ?
Are you running the latest prerelease firmware 3.7,2-pre3 ?
Also have the GRBL reports configured as such
Just installed 3.7.2-pre3 still seeing hesitation at 20,000mm/m over wifi. Even at 4,000mm/m its still having issue framing "rubber band" circles without hesitation & half second pauses.
This is what I'm framing, "a circle"
Here are some videos demonstrating the latest
4,000 mm/m "rubber band" frame over wifi issue https://youtube.com/shorts/4exAJKUqFTE?feature=share
20,000 mm/m square framing over wifi issue https://youtube.com/shorts/YvxsjkjuM_A?feature=share
20,000 mm/m "rubber band" framing one circle over wifi issue https://youtube.com/shorts/y2IZsKXxyQY?feature=share
Last but not least 20,000 mm/m "rubber band" framing one circle over USB, just so you can see how smooth it is over USB https://youtube.com/shorts/WoeVQ4yfGvE?feature=share
Attach the gcode and also attach the lightburn preferences file
Here are both, note that I have already removed the TCP connection, so you will not see that in the preferences. Let me know if I need to add it back.
When you say "over wifi", do you mean that you are using LightBurn with a TCP connection? Or are you using the FluidNC WebUI?
And the "jogs" mentioned above - were they issued with LightBurn or with WebUI?
I would like to see your LightBurn TCP configuration if that is what was being used when the problems occurred.
And the "jogs" mentioned above - were they issued with LightBurn or with WebUI?
I would like to see your LightBurn TCP configuration if that is what was being used when the problems occurred.
I misspoke, its still added. You should find the TCP connection in that preferences file.
It should be listed as simply GRBL.
The framing is issued through Lightburn. Jogging is not an issue, that is smooth. This is more with sending too much gcode too fast.
And yes using Lightburn with the TCP connection.
You said that jogging made WebUI crash. Is that no longer a problem?
Which version of lightburn?
Also I need to see the gcode for framing. The gcode file in the .zip file looks like a raster.
You said that jogging made WebUI crash. Is that no longer a problem?
Which version of lightburn?
Correct, that was only an issue on the 3.7.2-pre2. After the update I was able to jog without crashing.
Lightburn 1.4.00
Hmmm, no raster heres the lbrn file. It's a vector and some text.
Do you have an OLED display on your machine?
Do you have an OLED display on your machine?
No
Why do you have an oled section in your config file?
Why do you have an oled section in your config file?
I can comment out and re-test if that is potential issue. It was taken from Melvin's site, I have made minimal changes.
It is not a good idea to have unused sections. It is also not a good idea to take someone else's config file without looking at everything in it - unless you are sure that your system is exactly the same, which is almost never the case.
It is not a good idea to have unused sections. It is also not a good idea to take someone else's config file without looking at everything in it - unless you are sure that your system is exactly the same, which is almost never the case.
Understood, I have already reviewed the file in its complete form when originally flashed the device.
I did not realize this was the issue here. And this was on purpose, the more things that change the harder troubleshooting becomes. I like to change one thing at a time.
I don't know if oled is related to your problem, but I do know that I have not tested the case where there is an oled section with no oled.
I don't know if oled is related to your problem, but I do know that I have not tested the case where there is an oled section with no oled.
Nope, not related. Still an issue framing as the first video and mine from earlier today. Just tested again, here the current config now.
This pastes like junk, can't get the code or the quote thing working on github. Too many spaces. Oh well here it is, I can reupload as zip if needed.
board: XY-DLC32-MC V1.1 name: Sculpfun S30 meta: (06/20/2023) k. raab - S30 Pro Max 20w XY Extension - Refined Settings
arc_tolerance_mm: 0.002 junction_deviation_mm: 0.01 verbose_errors: false report_inches: false
start: must_home: false deactivate_parking: true check_limits: false
stepping: engine: RMT idle_ms: 250 pulse_us: 4 dir_delay_us: 0 disable_delay_us: 0 segments: 12
axes: shared_stepper_disable_pin: gpio.25 shared_stepper_reset_pin: NO_PIN
x: steps_per_mm: 80.000 max_rate_mm_per_min: 24000.000 acceleration_mm_per_sec2: 1000.000 max_travel_mm: 890.000 soft_limits: true homing: cycle: 1 allow_single_axis: true positive_direction: false mpos_mm: 0.000 feed_mm_per_min: 200.000 seek_mm_per_min: 3000.000 settle_ms: 250 seek_scaler: 1.100 feed_scaler: 1.100
motor0:
limit_neg_pin: gpio.34:low
limit_pos_pin: NO_PIN
limit_all_pin: NO_PIN
hard_limits: true
pulloff_mm: 2.000
stepstick:
step_pin: gpio.27
#change direction using direction_pin: gpio.26:low
direction_pin: gpio.26
y: steps_per_mm: 80.000 max_rate_mm_per_min: 24000.000 acceleration_mm_per_sec2: 1000.000 max_travel_mm: 900.000 soft_limits: true homing: cycle: 1 allow_single_axis: true positive_direction: false mpos_mm: 0.000 feed_mm_per_min: 200.000 seek_mm_per_min: 3000.000 settle_ms: 250 seek_scaler: 1.100 feed_scaler: 1.100
motor0:
limit_neg_pin: gpio.35:low
limit_pos_pin: NO_PIN
limit_all_pin: NO_PIN
hard_limits: true
pulloff_mm: 2.000
stepstick:
step_pin: gpio.33
#change direction using direction_pin: gpio.32:low
direction_pin: gpio.32
coolant: flood_pin: gpio.21 delay_ms: 0
Laser: pwm_hz: 1500 output_pin: gpio.4 enable_pin: NO_PIN disable_with_s0: false s0_with_disable: true tool_num: 0 speed_map: 0=0.000% 1000=100.000% off_on_alarm: true
user_outputs:
control:
safety_door_pin: NO_PIN reset_pin: NO_PIN feed_hold_pin: NO_PIN cycle_start_pin: NO_PIN macro0_pin: gpio.22:low:pu macro1_pin: gpio.17:low:pu macro2_pin: gpio.2:low:pu macro3_pin: gpio.16:low:pu
macros: startup_line0: startup_line1:
macro0: $J=G91 G21 F1000 Y10 macro1: $J=G91 G21 F1000 Y-10 macro2: $J=G91 G21 F1000 X10 macro3: $J=G91 G21 F1000 X-10
Here is my attempt to duplicate your problem. It works fine for me. This one is with 3.7.1 at 20000 mm/min. https://youtube.com/shorts/6uPyMOeNbL8
This is v3.7.1-pre3. Again, the motion is smooth https://youtube.com/shorts/nY921dVrqNw
The controller board is Fysetc E4 with this config file: e4_issue917.txt
I spent a lot of time instrumenting the Telnet/TCP code to see if it was behaving badly. I did not find any problems.
Here is my attempt to duplicate your problem. It works fine for me. This one is with 3.7.1 at 20000 mm/min. https://youtube.com/shorts/6uPyMOeNbL8
This is v3.7.1-pre3. Again, the motion is smooth https://youtube.com/shorts/nY921dVrqNw
The controller board is Fysetc E4 with this config file: e4_issue917.txt
I spent a lot of time instrumenting the Telnet/TCP code to see if it was behaving badly. I did not find any problems.
Interesting, I have done a bunch of testing here. Please let me know your thoughts on this, its seems my acceleration was initially set too low at 1000mm/s2 ??????!
Rubber band frame w/ acceleration at 500mm/s2 (notice how there is no laser showing) https://youtube.com/shorts/Jwnp45qbe5U?feature=share
Rubber band frame w/ acceleration at 1000mm/s2 (notice how laser is flashing rapidly) https://youtube.com/shorts/gSkuoJbZmHs?feature=share
Rubber band frame w/ acceleration at 1500mm/s2 (notice how laser is flashing LESS than before) https://youtube.com/shorts/MEyu2N-ER_Q?feature=share
Rubber band frame w/ acceleration at 2000mm/s2 (notice how laser is almost smooth) https://youtube.com/shorts/n0l3j8h-zIo?feature=share
Rubber band frame w/ acceleration at 2500mm/s2 (notice how laser seems the best?) https://youtube.com/shorts/xRQ1sylKVRE?feature=share
Riddle me this!? ISN'T 2500mm/s2 way too fast? Thats 150,000mm/m !?!?!?!?! I'm a bit confused here. What are your thoughts?
Here is a config file from when I first got the machine and it was running the OG firmware. It appeared back then as 1000 too! So confused....
And even Melvin's site recommends keeping this below 1000.....
TBH I dont even know how it was working this well over USB if its related to the acceleration.. They use the same config file!!
https://youtube.com/shorts/WoeVQ4yfGvE?feature=share
Now im really confused.!!!
Have you tried increasing pwm_hz to say 5000? That will make it possible to modulate the laser power faster.
High acceleration is not necessarily bad if your machine can handle it mechanically. It seems that you have linear rails which should help to keep the machine from shaking. At 2500 mm/sec2, it takes 160 ms to go from 0 to 24000 mm/min (=400 mm/sec). If the motors are strong enough to do that without stalling and the machine is stiff enough not to shake, then I don't see a problem with that acceleration.
I just did some testing on my cheap gantry. On the X axes I can do 14000 mm/min @ 8000 mm/sec2 without shaking. At higher speeds I hear a whining sound, perhaps from the rollers, and at higher acceleration I hear a clunking sounds when it starts and stops. I did not test the Y axis this time, but I know from previous tests that it cannot go as fast, likely because of more moving mass.
Update - Y is quiet at 10000/2500 and starts to whine a bit when the rate goes above that, and clunks with higher accel. It's an EleksLaser gantry with roller bearings, NEMA17 motors (dual drivers on Y), 370x295 working area. Pretty low end gear.
Have you tried increasing pwm_hz to say 5000? That will make it possible to modulate the laser power faster.
High acceleration is not necessarily bad if your machine can handle it mechanically. It seems that you have linear rails which should help to keep the machine from shaking. At 2500 mm/sec2, it takes 160 ms to go from 0 to 24000 mm/min (=400 mm/sec). If the motors are strong enough to do that without stalling and the machine is stiff enough not to shake, then I don't see a problem with that acceleration.
I just did some testing on my cheap gantry. On the X axes I can do 14000 mm/min @ 8000 mm/sec2 without shaking. At higher speeds I hear a whining sound, perhaps from the rollers, and at higher acceleration I hear a clunking sounds when it starts and stops. I did not test the Y axis this time, but I know from previous tests that it cannot go as fast, likely because of more moving mass.
No luck, the laser behaves worse at 5000pwm/hz.
Streaming GCode over WiFi is inherently unpredictable. WiFi maximum transfer speeds are higher than serial, but only for long payloads, and the latency and predictability are much worse. For short packets, WiFi has very high overhead. The GRBL protocol was designed for serial on an 8-bit microprocessor with limited RAM, so the transfer length is very short - limited to 128 bytes outstanding. At 128 byte payload lengths, WiFi is very inefficient. I do not think that is possible to guarantee good performance when streaming GCode over WiFi using the GRBL line protocol. That is why WebUI only supports running GCode from a local SD card.
In principle, it would be possible to define a streaming protocol that is tuned to work well over WiFi, but it would require changes at both the controller and sender ends. It is an uncommon use case in the GRBL world so it is unlikely that developers at either end would be willing to implement it, and implementing on just one end would be useless.
At this point I have already spent too much time investigating this, to the detriment of other tasks that benefit more users.
Maybe a few things to add from my side:
My bottom line is, you are trying to run the laser far beyond specifications and all the problems mentioned here are neither Fluid nor hardware related. It's just the way things are. There was nothing really unexpected in your videos. WiFi is not suited for this task and the hardware is not meant to be run that fast.
Of course, you can try to run it at these speeds (and if you find a fitting configuration, that would be great!), but it's up to you to find those parameters. There is not much that can be done from the software backend side.
Thank you Mitch and Melvin for your considerable time on this and exploring all the options here. I will close this.
Controller Board
Sculpfun S30 Pro Max 20w Laser MKS DLC32
This is an image of the exact board in use https://diode-laser-wiki.com/wp-content/uploads/2023/03/S30-Pinout-1024x787.png
Machine Description
Sculpfun S30 Pro Max 20w Laser with XY Extension 890mm x 900mm
Input Circuits
No response
Configuration file
Startup Messages
User Interface Software
Lightburn
What happened?
I ran a job in Lightburn and it failed, multiple times. Seems that Wifi connection is slow which causes the X axis to forget what its doing.
You can see here how slow the Wifi connection is compared to USB.
This is operating over Wifi, you can see the belts shaking violently and how slow it is to frame the job. https://youtube.com/shorts/TymS4qBxlb0
This is operating directly over USB/Serial and appears to have much smoother movement. https://www.youtube.com/shorts/4KRMixaf-WA
Other Information
No response