Replies: 31 comments 70 replies
-
|
Link to specification? This could be implemented as a plugin that expands these blocks back into standard gcode as the purpose of this compression is mainly to overcome serial port bandwith limitations? FYI I have managed to push the iMXRT1062 driver to > 70.000 mm/min by tuning the planner buffer size. Its native USB CDT transfer speed is > 400kb/s so way beyond the more common 10kb/s that most older board uses. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @terjeio there is no specification as such, but this has been enabled for Smoothie 3 years ago. I've probably done more testing for speed than anyone, iMXRT is so fast it does not need cluster, but is too expensive. Realistically Teensy 4.1 can go up to 40kmm/min for high resolution with a properly tuned planner. For instance at 30kmm/min it takes 8:15 through USB and 7:49 through SD for 423dpi greyscale, 10kmm/s/s xy accel, 100x100mm. Teensy is more than fast enough and not the motivation. Realistically most motors tap out at lower speeds. But we definitely need the 4x performance boost for ESP32 which has all the bells and whistles, but lacks true Teensy like speeds and even 20kmm/min would be excellent. Realistically for 423dpi less than 5kmm/min is achievable with a well tuned ESP32 without cluster. |
Beta Was this translation helpful? Give feedback.
-
|
Raw speeds (check mode) with the smallest file (~20M, Test-10k423dpi_0Deg_Cluster.nc), streaming from SD card: STM32F756 - 09:06, 37kb/s (single lane SD card, no DMA). This is by decoding the data by hijacking the input stream and feeding the decoded data to the parser. The code is rather crude, cobbled together quickly. NOT tested with a machine (only check mode) so hopefully the decoding is correct. SD card streaming only. I do not know what the M107 commands at the start and end of the file are for, these has to be removed or streaming will fail. |
Beta Was this translation helpful? Give feedback.
-
|
Have been looking a bit more at the H7 performance this afternoon. Check mode for the ~36MB file is streaming from SD in 02:44 (vs 0:46 for the Teensy). That's using 4-bit SDMMC with DMA, but can see it's still falling back to the scratch buffer (memcpy) path for cache alignment reasons. |
Beta Was this translation helpful? Give feedback.
-
|
Bit more poking around on the H7, turns out is not related to the scratch buffer use (have been changing my code to cope better with unaligned buffers), but just the small reads. Here is a chart of the FatFS read performance I'm getting from another test program, is best case I think. Incidentally it tops out with 8K reads because that's the cluster size on this (32GB SanDisk) card, increasing that should help further. I guess the sdcard plugin is reading 1 byte at a time because it's replacing a regular input stream? Reading that 36MB file would take 2:07 with single byte reads.. Just thinking aloud, I wonder whether the sdcard plugin could perform some local caching of larger reads?
|
Beta Was this translation helpful? Give feedback.
-
Isn't FatFs taking care of that by reading whole sectors from the media into a buffer as needed and individual reads is from that buffer? There were cache issues in the iMXRT1062 uSDFS implementation that had to do with reading/writing sectors - I patched the BTW further buffering at a higher level could be implemented in the VFS wrapper for FatFs - this would benefit all the code reading single bytes. |
Beta Was this translation helpful? Give feedback.
-
It does only read each sector once yes, but each subsequent call to f_read() for the buffered bytes also checks the card status, which is I think where all the time goes. In the ST driver, this actually queries the card - which is maybe not the case for the Teensy? Profiling the program counter, it's just constantly sat in SDMMC_GetCmdResp1() waiting for the card response..
I think the higher level code is okay. I suspect I was being too paranoid about falling back to scratch buffer use, due to some initial problems with corruption around cache boundaries. But after looking at other implementations (including your iMXRT1062 code), I believe this is now taken care of. My local branch is now only using the scratch buffer if the passed buffer is not 4 byte aligned for DMA access, and just performing some additional cache management if not 32 byte aligned. Still testing, but have written and read 100's of MB so far without any corruptions..
I do think something like this is going to be needed for the ST drivers yes.. |
Beta Was this translation helpful? Give feedback.
-
|
@terjeio this looks very promising. For a deep greyscale which means almost no S0's it cuts engraving time by almost 50% Cluster (20MB) file) Check Mode on ESP32 - 6:44 Doing more testing today. |
Beta Was this translation helpful? Give feedback.
-
|
@terjeio unfortunately something is not working correctly. The X movements are incorrect as the engraving is 100x100mm with 7.5mm overscan, and offset by 50x50mm X,Y. So X travel range should be 42.5 to 100.75mm. In cluster mode it moves to X >300mm. If fixed this could improve the engraving time. Secondly, the Spindle Enable pin is behaving sporadically. In Laser mode I believe that the spindle enable should turn on with M4 and off with M5 only. Even a S0 or misinterpreted gCode should not disable the spindle. This may be an issue with non-cluster, but cluster makes it more apparent. |
Beta Was this translation helpful? Give feedback.
-
|
Try this, I forgot to divide the distance by number of clusters - still work in progress...
I have to check this, but IIRC S0 switches off the spindle enable signal as standard. BTW |
Beta Was this translation helpful? Give feedback.
-
|
@terjeio, thank you. I will test and report back. |
Beta Was this translation helpful? Give feedback.
-
|
There is a missing ++ in line 109, should be
$9?
|
Beta Was this translation helpful? Give feedback.
-
|
@terjeio Cluster is working much better. On the other issue, I've been using $9=1 and the spindle enable pin has been going on and off with M4 during engraving and it should remain on. After M4, the spindle enable pin is high, G1 X7.5F40S0 will keep the spindle enable pin high through the motion, then turn off the enable pin at the end of the motion. This requires M5 followed by M4 to enable the spindle pin while not in motion (for some reason M4 alone will not re-enable spindle once it is turned off at the end of motion). I am running that cluster gCode at 40kmm/min, with 10kmm/s/s accel for x and y. Can you please confirm this on your end as it seems higher accel causes the issue more. Sometimes it will even crash at higher acceleration, but at much lower accel such as 1500mm/s/s it will not disable the spindle while streaming. It's appears at higher accelerations it is going into idle and at lower accelerations it is constantly moving. |
Beta Was this translation helpful? Give feedback.
-
|
There is a "bug" in M4 handling of the spindle enable signal in laser mode, fixed in the latest commit. If you set acceleration, max feedrate and steps per mm to values that results in step pulses beeing output close to or faster than the latency I would expect things to fall apart. I do not know what the latency (or the max step frequency) is for the ESP32, you can check that? |
Beta Was this translation helpful? Give feedback.
-
|
@terjeio excellent on fixing the issue with M4, I am doing more testing. I updated but now finding that WebUI has only ESP file upload and Terminal. It lacks jog controls, SD controls and other things. Is there something simple I'm missing? |
Beta Was this translation helpful? Give feedback.
-
It is likely the new flash file system maintenance page - upload the WebUI index.html.gz and reopen the page. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @terjeio I tried that many times. That file on your repo is only 11KB, I uploaded an older version 77KB and it was WebUI V3, but it did not work. I found an even older version 125KB and it works fine and has all the features, but it looks like WebUI V2. |
Beta Was this translation helpful? Give feedback.
-
|
ok, happy to report further testing I found the issue with crashing and not finishing processing was a corrupt SD card. 40kmm/min and 10kmm/s/s settings for a 100x100mm at 423dpi. I hope Cluster USB speeds are close to Cluster SD. It is possible to enable a test version so I can compare. The |
Beta Was this translation helpful? Give feedback.
-
Non-cluster USB was 5.0 minutes? Or should it be 50.0?
Yes - I have to approach reading from a live stream differently than reading from a file as the former may return |
Beta Was this translation helpful? Give feedback.
-
|
Hi @terjeio, yes 50 minutes streaming through USB (I edited the comment). There seems to be true benefit to speed to this work. |
Beta Was this translation helpful? Give feedback.
-
|
Try this: There is at least one issue, streaming from a sender will break after a soft reset. A core change (a new event?) is required to fix that. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @terjeio it looks great! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @terjeio I just found out Lightburn will be using up to CLUSTER:16. |
Beta Was this translation helpful? Give feedback.
-
|
Where? Do you have a link? Asking since I will put the code in the Plugins_laser repo and it would be nice to have a link to some information about clusters. I'll add a #define symbol for configuring the cluster size in the next commit, maybe out tomorrow. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @terjeio, no documentation anywhere to my knowledge, the LB developer messaged me details. Please see updated comment above about Svalue scaling. Should be processed as usual. I have yet to install the new version of Lightburn that generates the code for grbl. But when I do I will provide some test gCode. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, thanks.
This means no scaling? Or scaling if $30 <> 1000? |
Beta Was this translation helpful? Give feedback.
-
|
Each SValue is scaled by $30 just as usual with grbl. So if $30 is 1000 and Svalue is 500, PWM is 50%. Basically Lightburn requires the user to input Smax and Smax is aligned to to $30. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, I have just commited a new build that includes the cluster plugin. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @terjeio attached is real Cluster 16 gCode. Using VER:1.1f.20220922 and my_plugin.c It is working great when streaming through SD card but trying to stream this code through USB using Lightburn causes USB to lose connection. I cannot lead the code through IO sender because it barks at me for every line. The code is actually 1/10 of the original code so when running through SD it takes a little less than 2 minutes which means the full code runs in less than 20minutes (compared to just under 40 minutes with non-Cluster). Also Lightburn looks for [CLUSTER:16], not {CLUSTERS:16] Thank you! |
Beta Was this translation helpful? Give feedback.
-
Which driver? I am testing with STM32F7xx, works ok with that - via a USB <> UART bridge.
I know, the gcode parser has to be modified to allow its use. I have tested with Candle, it is the only sender that works for me.
Ok, will fix. |
Beta Was this translation helpful? Give feedback.
-
|
Just saw that the S-values allows for 10.000 levels - any good reason for that? The fractional part of the S-value could be rounded off? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @terjeio I am using ESP32 I am testing to see if this is a latency issue introduced by faster gCode processing. I have been using 40kmm/min max velocity and 10kmm/s/s for max accel in all testing, but obviously not achieving that max velocity VER:1.1f.20220922 and my_plugin.c
VER:1.1f.20220925 with lb_clusters.c OPTION(Laser "Use LB Laser Clustering" ON) CMakeLists.txt |
Beta Was this translation helpful? Give feedback.
-
|
New build with updated CMakeLists.txt and fixed |
Beta Was this translation helpful? Give feedback.
-
Ok, to be pendantic: this driver does not have native USB support - it uses UART via a USB <> UART converter chip.
"Connection lost" means what? The ESP32 has crashed or the USB <> UART chip has crashed? The latter sometimes happens for me when I connect through a USB hub - I have to unplug the USB cable to reset, pressing the controller reset button does not fix it. Your test program runs via Candle on my ESP32 and STM32F7xx boards with no issues, but with more sensible settings? 250 steps/mm, 15000 mm/min max speed and 3000 mm/sec^2 accel. BTW have you calculated the max step rate and set $0 accordingly? The default 10 microseconds will only work up to approx. 80KHz. I'll commit an update with a fixed CMakeLists.txt and the laser submodule added a little later. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @terjeio
I understand, in fact I'm using the more reliable SI Labs CP2102.
I'm not sure which, but I suspect USB to UART has crashed. I was not able to follow what was happening in candle. In the IO sender you linked which is Cluster compatible I got errors like this. { Status_GcodeCommandValueNotInteger, "G-code command in block requires an integer value." }
I now believe the errors are occurring even if the file completes streaming. I'm still testing more, but all of this is stacking up like a communications issue or a USB to UART error. Still doing more testing. Willing to try other things... |
Beta Was this translation helpful? Give feedback.
-
It seems so, and it looks like the errors happens in random places. I have just retested with your file with numerous runs for both ESP32 and the F7, and I ran some tests with the iMXRT1062 yesterday, all successfully completed. |
Beta Was this translation helpful? Give feedback.
-
|
@terjeio which H7 are you using, the Mini (H7B0) at 280MHz or the Core (H750) at 480MHz? Does it work with BT and WebUI? |
Beta Was this translation helpful? Give feedback.
-
|
@dresco has made the H7 driver, I am using a NUCLEO-F756ZG development board. |
Beta Was this translation helpful? Give feedback.
-
|
@troth530 My H7 driver is using the single core H743 at 480MHz. I've been testing with BTT SKR 3 (EZ), Nucleo-H743ZI2, and WeAct MiniSTM32H743 boards, and am planning to layout my own controller board as a winter project. Out of those three, only the Nucleo has Ethernet, so I've added WebUI to that one (needs a SD card breakout though).. The BTT board has an ESP WiFi interface which I've not looked at yet. I'm assuming this would just have the serial input stream running over it (so no good for WebUI)? |
Beta Was this translation helpful? Give feedback.
-
|
FYI Little bit info from LB staffhttps://forum.lightburnsoftware.com/t/cluster-mode-for-grblhal/77711 Cluster for Grbl: Cluster on G code devices has also been set up to allow up to 16 brightness values per cluster, and it looks for [CLUSTER:xx] as a response to the $I command. If it sees that response, it pulls the number out of the argument there, and uses that as the cluster size, clamped to be a value between 1 and 16. |
Beta Was this translation helpful? Give feedback.
-
|
@terjeio and @dresco , first of all, thank you for all of the hard work you do! I'm interested in knowing how long it takes to execute the cluster code on WeAct MiniSTM32H743. Looks like that has 2MB ROM versus the WeAct MiniSTM32H750 which has only 128KB ROM (I think grblHAL is about 64KB) and 743 is no longer available. I will see how fast it will run on Teensy 4.1. |
Beta Was this translation helpful? Give feedback.
-
|
I'll give it a try next week & see how long it takes to run (I would expect SD card streaming to be slower than the Teensy, as the current code results in a card access for every byte read).. I did ask WeAct when the H743 board dropped off their store, and they said was just an availability issue, so expecting it back at some point.. The 743 vs 750 situation is a bit interesting. Was rumoured that the 750 parts were just 743 that had failed flash validation. No idea how true that is, but I believe someone has successfully run the existing code on a 750 (including saving settings to the last 128KB page of the 2MB flash that shouldn't exist!). Regardless, those WeAct boards also have external flash chips, so should be possible to run the code from external flash with a bit of effort.. |
Beta Was this translation helpful? Give feedback.
-
@troth530 Have just done some initial testing, with 300 steps/mm & 10,000 acceleration, your smaller cluster file is running from SD in ~01:40, and my best time over USB was ~02:04. The USB performance was a bit flaky (would repeatedly stall for a few seconds) but I was running ioSender in a VM so the problem might well be on the PC side.. |
Beta Was this translation helpful? Give feedback.
-
|
@dresco awesome. This is exactly the mapping I was looking for. As I looked at the schematics there are a few things that are allocated, but not used unless you install peripherals. I'll want to add a 4th axis. Contact me through email... my username [email protected] so I can know where to ship a prototype to you if you're interested. I usually wire a prototype into an existing board, but this looks mature enough to start layout. I tend to design for lasers with common enable pin for all motors other minor simplifications, but I've got a good power system, transceivers for outputs and optocouplers for inputs, so I may try to keep it generic for even CNC for not. As far as used pins, I understand your point, but oddly the chip alone costs more than the dev board with chip installed at least the way you or I would purchase it (small quantities). I see enough spare pins to be more than enough for 6 axes and all grbl functions and TMC UART. Can PA9, PA10 be used for bluetooth? WebUI would be nice to have to upload to SD. Anything wireless would be the icing on the cake. Just an idea :) |
Beta Was this translation helpful? Give feedback.
-
Yes that's what I meant. Looks like it works on a wired connection. Was hoping for wireless. I wouldn't trust wireless for streaming, but very useful to jog and upload to SD. |
Beta Was this translation helpful? Give feedback.
-
Cool, will do. Happy to try & help get it up & running. Are you still looking at the H750? If so, may need to get it running from the QSPI flash..
Yes, should be able to. I don't see an obvious reason why you couldn't use an ESP with WiFi-serial bridge firmware also?
I think Terje has implemented ymodem file transfer over the 'serial' stream, so uploading may still be possible from the right sender?
I believe they are all free, though I'm likely to use D0 & D1 for CAN in my map (I think they are my only available option on this board). |
Beta Was this translation helpful? Give feedback.
-
@dresco I'll just use PE0 and PE1 for A enable and limit. Reminding myself to read the H7 datasheet. I'm interested in using open drain for stepper enable. I believe this will enable connecting for instance X and Y so that X and Y are both locked when either X or Y is moving. Please confirm. Also in your pinmap PA7 is used for Safety (if enabled) and Trinamic MOSI. I'd be interested in looking more into the ESP bridge idea. This would be done through UART? |
Beta Was this translation helpful? Give feedback.
-
FYI the F4xx driver (and, IIRC, a few others) has the option to declare step, direction and enable pins as open drain. IMO other drivers should implement this option in the same way.
Yes, AFAIK the ESP32 does not support native USB host mode. Since I now have all the needed components I am contemplating implementing a standalone Pi Pico W bridge and also adding bridge capability to my MPG & DRO project. This could even support a USB connection to the controller if the Pico is capable of USB host mode. |
Beta Was this translation helpful? Give feedback.
-
I think open drain support for the stepper outputs is already in the H7 driver (inherited from the F7 driver), haven't tested it though..
Good spot, thanks! Feel free to change it to whatever unused pin suits your design, and I'll update the map file accordingly. (I'll also add your 4th axis definitions).
Tbh I was thinking of one of the older / cheaper ESP8266 based modules, BTT for instance use these for serial WiFi bridging.. Not sure whether this would be completely transparent, or if it would need a plugin like the HC05 bluetooth module? Edit: for reference - found a couple of ESP8266 firmwares for telnet & WebSocket bridging.. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @terjeio for some reason IO Sender can run the cluster gCode pefectly but I cannot run cluster from Lightburn using ESP32 Wroom with the Silabs 2102 USB to UART. Non-Cluster code works great, cluster code loses USB connection. Did you add any flow control with the Oct 9 build? |
Beta Was this translation helpful? Give feedback.
-
No. What do you mean by losing connection? The 2102 crashes and you have to power cycle to be able to connect again? I have that problem occasionally when I connect through my USB hub. |
Beta Was this translation helpful? Give feedback.
-
|
@terjeio, yes the 2102 crashes and needs a power cycle. I am not connecting through a USB hub, but I will check with a different power supply setup. |
Beta Was this translation helpful? Give feedback.
-
|
@terjeio and @dresco I just tried with the STMH750 and same behavior... it looses connection in Lightburn. Runs great through IO sender and SD card. I am also reaching out to the Lightburn developers. BTW, great job on STMH7 @dresco! If we can figure out a way with @terjeio's help to bridge WiFi it would be the complete package. The WiFi bridge may need dedicated pins for Tx & Rx it is listening for data. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @terjeio. I'm still testing trying to determine why the ESP32 crashes in Lightburn. As part of the testing I had to develop a test to see if data was being lost. As far as I can tell for non-Cluster all the data is being read properly. But there seems to be an issue with float precision. This is relative code and most of the movements are in the same direction to see if errors accumulate. This code at the end of engraving should return exactly to 0,0. But instead returns to 0.413,0. This is true for SP32 and STM32H7. I also modified the gCode so that the S values proceed the movements, This placed the movements at the end of each line to see if data is being lost as losing a digit of a S value is not as apparent as a loss of a digit for movement. As far as I can tell there is no lost digits and the issue is precision. Please run this code and you'll see the finish position is 0.413,0 instead of 0,0. Also Lightburn gCode uses 3 digits and it does require the 3rd digit to move correctly. For instance a scan gap of 0.06mm with Cluster16 would look like this. These 2 issues do not fix the Cluster issue as I've been trying to debug this for the past 3 weeks and still looking. |
Beta Was this translation helpful? Give feedback.
-
I am not so sure this would help if the error is from float (im)precision. A previous test file (TestCluster10mmCluster16.nc) with 3 fractional digits:
and 6:
BTW the test file above is a bit odd, there is a X159.918 return move after a bunch of 0.06 moves (or mutilple thereof) - that does not add up? A thought: each raster line should end with a absolute move to avoid precision (and/or rounding) errors to accumulate over the complete job? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @terjeio. The gCode I uploaded is a little bit modified by me by mistake but in fact it does return to zero due to an extra movement I added at then end. I wrote a python program that confirms return to zero is enable by the gCode. I do my best to filter out my mistakes before reporting to you. The good news is that the adjustments to cluster.c eliminated the accuracy introduced by cluster but there is still 0.3mm error at the end of the engraving which is now the exact same amount for both cluster and non-cluster in IOSender. Still Lightburn streaming does not work for both ESP32 and STM32H7. Can you please download a 30day demo from here to test on your end. If you contact me though the gmail address I sent @dresco above I will pay for a License key for you. It's the least I can do for all of your help. @dresco. I don't know how much testing you've done on the STM32H7, but today I built an adapter that enabled me to pug into my existing 4 axis design and it works great! Limits and homing works, 4 axes all moving as they should . I completed an engraving today and movement is accurate and PWM looks very clean. Pause/Resume/Stop do what they should. I did not test probe or safety, but I did test Mist with a relay. I also did not test UART. It's quite fast and frankly quite adequate. I did see one issue but I did not get a chance to see if it is a core grblHAL issue or a driver issue. But when any stepper is active all steppers are locked. I don't believe that is the intended behavior. If STEPPERS_ENABLE_PORT and STEPPERS_ENABLE_PIN is defined then it make sense that any single active stepper will lock all steppers. However even when I define individual enable pins for each motor, anytime I have an active stepper, all steppers are locked. You guys are awesome!!! Thank you! |
Beta Was this translation helpful? Give feedback.
-
Cool, if you have a map file or anything that you want included then just let me know. I think I only have 3 axis defined for the WeAct board currently..
You are right, I don't think that is H7 specific though, so perhaps intended behaviour? |
Beta Was this translation helpful? Give feedback.
-
|
I have tested with the demo LightBurn, it looks like cluster mode transmission is broken as the serial input buffer overflows both in buffered and synchronous modes. A bug in LightBurn? I tested with the Grbl device profile.
This is per design, when motion is started all steppers are enabled. |
Beta Was this translation helpful? Give feedback.
-
|
@dresco I will email you. Almost done with adapter board. It won't have all the features due to limitations with my current base board, but I am working on UART and will enable a WIFI module for development. I previously had issues with addressing using UART (single pin for all drivers) and due to time constraint had to drop it. Due to available IO on STM32H7 I will be using your proposed UART pins. @terjeio I finally figured it out!!! Cluster processing is sending an OK response after the first Svalue. This is expected behavior. But then a second OK response after the second SValue for the same line and only 2 OK responses per line. Due to the way Lighburn sends, each OK response from the controller triggers more sending from Lightburn. However if the other Svalues are still being processed by the controller and the controller is not ready for a new line a pile up occurs. This is probably so simple thing for you to fix. Thank you!! |
Beta Was this translation helpful? Give feedback.
-
No, logging is before filtering. The reason behind the bug is that ioSender uses CR as line terminator and LightBurn uses LF. Line 287 adds a LF to the data which is removed by the input stream handler when the previous character is CR but not when it is a LF - the additional LF is causing the extra ok to be output. And the reason for why the my_plugin.c version was working is likely because it parsed and multiplied the S value with the max RPM setting? - this removed the original LF. |
Beta Was this translation helpful? Give feedback.
-
I'll comment out that line and report back. |
Beta Was this translation helpful? Give feedback.
-
|
@Terjio, I think cluster is working perfectly with the extra LF commented out and the added precision. Can the precision on grbl be likewise improved as there still is 0.3mm accumulated error on a 10mm engraving (albeit exaggerated as unidirectional and relative movements with 3 digits required). |
Beta Was this translation helpful? Give feedback.
-
|
@dresco STMH7 is looking good too. Thank you gentlemen! |
Beta Was this translation helpful? Give feedback.
-
grblHAL uses float for storage and calculations as this allows the use of the FPU that many of the supported MCUs has. Changing to double for calculations will, IMO, impose a performance hit that should be avoided. Longer term I am considering adding double support as an option since the iMXRT1062 and STMH7xxx has double precision FPUs. However I do not think this will make much of a difference for most users so not a high priority for me. To be noted is that the string to float conversion function might play a part in limiting precision as max number of digits read is 8, and the digits are read into an integer value before beeing converted to float. Anyway, using hundreds of thousands of incremental moves is a bad idea when finite precision calculations are involved. And as I wrote earlier, one could get rid of (most of the) accumulated errors by switching to an absolute move on one or either end of a raster line.
Where is this requirement coming from? BTW can you upload the 10mm engraving file so I can take a look at it? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @terjeio, I've been tracking down theses issues for a while. Any engraving in Lightburn that uses Start from: Current Position will use relative coordinates. The Lightburn developers track 3 digits (not traditional 2). In prior versions of LB they only used 2 digits but added the 3rd to eliminate banding. Most people don't understand stepper movement and magic numbers (don't get me started). Any image not perfectly aligned to a grid based on the line interval will require this treatment. So it happens most of the time. In the function you pointed out should I experiment with changing if c<=9 to c<=11 or adjust MAX_INT_DIGITS in nuts_bolts.c? Attached is typical gCode, Unidirectional to highlight the precision and a utility script I wrote that will track relative movement you can adjust the number of digits between 2 and 3 in the function call. Thank you. |
Beta Was this translation helpful? Give feedback.
-
MAX_INT_DIGITS - but it does not help. It seems to me that the issue is that float can only store a finite number of values, and adding a large number of values will always lead to loss of precision. E.g. changing line 11 to G0 X30Y59.014 reduces the error to 0.099, simply because the precision is better in the range used for calculations? As a test I enabled expression support, recorded the start position with G30.1 (at line 12) and returned to it on the start of each line with the following code: instead of This seems to work - but is of course not a generic solution. So how to fix this? Switching to double and lose single precision FPU speed gains is not an option as this is likely to cause problems with a large planner buffer? |
Beta Was this translation helpful? Give feedback.
-
Any raster engraving at all will use relative coordinates - LightBurn will use absolute coords for cuts, but regardless of the mode, engraving always switches to relative, because the generated GCode is almost always shorter. I output 3 decimals of precision in metric, and either 4 or 5 in imperial, and I internally track the rounding error between the actual generated coordinate output and the emitted one, and account for that as well so it shouldn't drift over time. If you internally track the values as integer, scaled up to whatever your maximal precision is, then convert to float for whatever stepper math you need to do, that eliminates the drift. For example, instead of internally reading "10.099", convert that to 10099 (integer), then just /1000.f before doing any stepper math. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @terjeio, during testing 2209 UART on STM32H7 I am finding some bugs with both H7 and ESP32. The implementation is different as H7 uses a single pin per axis (thanks for the tip @dresco) and ESP32 uses addressing with single pin for each driver and 2 pin UART on the controller end. I tried defining only a RX pin for ESP32 and it did compile but would not communicate to the 2209s. Here's the ESP32 implementation... In addition to the settings in CMakeLists.txt, ESP32 I added the board to trinamic_if.c and added these lines to map file For ESP32, it seems M122 is only reading from the x-axis driver for microsteps. For instance if you all axes set to default of 16 microsteps, if you set $150 to 8. All axes will report 8 microsteps with the M122 command. Also I believe the axes are not just reporting the same microsteppering as X, but also physically using the same microstepping as X based on movement. The H7 reports separate microsteps for each driver according to 15x setting as it should. I don't know if this is related to the addressing used only on the ESP32 or perhaps how the $ values are setting the driver. For both ESP32 and H7 at any time I can unplug PDN_UART from any axis and M122 will continue to report for all axes (as if the axis is still connected). However M122i will indicate it cannot communicate with the stepper. Also @dresco indicated to me that he can read realtime stallguard readings from each axis, so I'll experiment a little more with the debug output especially M122 X S1 and so on. I believe these ESP32 addressing were issues were part of what I was reporting near the end of this issue grblHAL/ESP32#33 Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
For the ESP32 TMC2209_HWADDR should be OFF and MS1/MS2 wired to provide the matching driver address when a single UART is used. X = 0, Y = 1, Z = 2, M3 = 3. Since I do not have a board available for the ESP32 that supports Trinamic drivers it is not easy for me to fully test the interface code. I guess I could breadboard a complete setup but have not done so yet...
Correct, data should normally be all 1s or 0s (or random bits) depending on the state of the UART input(s). It is possible to add CRC validation for UART mode drivers and output an error if it fails, but this is not possible for SPI mode drivers (other than checking for all 1s or 0s returned from certain register reads). I have limited comms ok check to the init function for now. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @terjeio, yes it was 2209 addressing that was causing the problem on the ESP32 device. I have not started testing H7 yet. Also stallguard slow threshold (sgst) does not seem to be read even with $339 set. In the case below $339 is set to 1 Thank you! |
Beta Was this translation helpful? Give feedback.
-
You are aware that the TMC2209 stallguard output is not open drain and thus cannot be wire-or'ed with limit switch input? Stallguard tuning is not trivial, see the TMC2209 reference manual. Compile time parameters can be (or rather has to be?) adjusted to match the mechanical configuration of the machine. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @terjeio I will try IO sender. I'm expecting a lot of tuning work is needed. When using debug M122 X S1, SG value while moving with no resistance on the motor is >350. Moving with resistance on the motor several times the SG value goes below the threshold and the limit is not triggered. I'll verify with a scope the diag pin output. |
Beta Was this translation helpful? Give feedback.
-
Not a concern, I'm using single pin limit per diag pin. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @terjeio, I set $5 to zero, set $26 to 0. $338 and $339 are both set to 15 (xyza axes). M122 does not read a SG threshold. $200-$203 and $220-$223 are both set to 22. I also verified that the diag pin does not go high when SG result is higher than SG threshold. Please note that in my comment 2 days ago SG threshold was set and I don't know why it can't be set now. I found the same behavior for STM32H7 and ESP32. M122 |
Beta Was this translation helpful? Give feedback.
-
|
Can you set the SG threshold with M914? FYI the SG threshold is not read from the driver chip but from a shadow register. IMO TMC2209 stall detection should not be used as a replacement for limit switches in normal operation since a stall detection parameter (TCOOLTHRS) is dependent on the step pulse frequency (feed rate & step pulses per mm). And if limit switches are allowed either separate inputs for DIAG pins and limit switches has to be allocated or the signals has to be somehow or'ed together. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @terjeio I verified I can now read SG threshold with M122 after using M914. I will do more testing with sensorless homing but in general the intention of stallguard is either homing or basic limits... it hits a hard stop (motor damaged, missed steps causing the motor to hit, user setup, etc...). I scoped the signals and diag pins are going high but limits are not being triggered. Independent of stallguard, I believe that limits are not working with $5=0 and $21=1. I injected 3.3V and 5V signals directly to the limit pins and hard limits were not triggered. I also checked IO sender and the pins are in fact going high (the correct pin lights up in the Signals section of IOSender- X, Y or whatever pin). This is true for both STM32H7 and ESP32. Can you please check on your end hard limits with $5=0 works as I need to run a custom config due to my hardware. This is with $338 and $339=0, but I don't think it matters. Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
I seems the freeRTOS task scheduler messes things up for the ESP32, perhaps due to the debounce handler beeing run as a foreground process?
after line 105 in machine_limits.c. A better approach would be to wrap the debounce code in a critical section? I do not have time to test that now as I am about to leave... |
Beta Was this translation helpful? Give feedback.
-
|
Hi @terjeio it seems STM32H7 and ESP32 have the same response. Hard limits ($21=1) will not trigger either NO ($5=15) pulling limit pins to ground and will not trigger NC ($5=0) pulling limit pins to 3.3V or 5V. In all cases $18 is set appropriately. The above code was added and did not change the results for ESP32. I will test for STM32H7. Update: STM32H7 does not trigger hard limits either. Homing works on both ESP and STM. Further Update STM32F1xx does not trigger hard limits, but with earlier builds hard limits are triggered. "Earlier builds" I only went back to GRBL_VERSION_BUILD "20210604" for the STM32F103 and did not have any more recent versions to test. So hard limits stopped working sometime between June 2021 and current. |
Beta Was this translation helpful? Give feedback.
-
|
When I tested with my ESP32 before I left (for a 2 month holiday) hard limits were working. I have only a STM32F756 available for testing here and that works too. @dresco, can you check hard limits for the H7? |
Beta Was this translation helpful? Give feedback.
-
|
@dresco, my testing on the H7 showed the limit pins switching state in IOSender, but no alarm when limits are hit even with $21=1. This seems to also be independent of debounce (I tested with $26=0). Please confirm. As with STM, ESP, and likely Teensy homing works, but not hard limits. BTW, sensorless homing also works. Overall your driver is passing every test I've put it through! |
Beta Was this translation helpful? Give feedback.
-
|
@terjeio @troth530 |
Beta Was this translation helpful? Give feedback.
-
|
I realize I'm late to the party here, but I'm the LightBurn developer who came up with clustered GCode, originally to get around the speed limits of Smoothieware's CPU constraints. I don't have a specification, but I could write something up relatively quickly if you think it would be useful for you, and feel free to ask me questions if you have any. |
Beta Was this translation helpful? Give feedback.
-
|
I do not believe need a specification anymore as the protocol is quite simple - I like that. |
Beta Was this translation helpful? Give feedback.
-
|
@JasonDorie welcome to the party. @terjeio I was able to implement cluster on Smoothie 2.08 (as I recall), it was 2x slower on a LPC1768 (rearm at 100MHz) compared to STM32F1 (Blue Pill at 72MHz), both had no FPU. Overall grbl and more specifically grblHAL is faster than Smoothie. |
Beta Was this translation helpful? Give feedback.
-
|
If your firmware accepted [CLUSTER:9999] would you just get the entire scanline encoded an S parameter, or just clamp at 16 and send those sized chunks? You don't write specs for some of these people rather to point to when people ask GRBL proper to implement the protocol. |
Beta Was this translation helpful? Give feedback.
-
If buffers are sized to accomodate the data then the entire scanline will be decoded.
I guess so - by tuning the spindle settings accordingly.
Not with the current implementation.
This statement did not make sense for me. I have implemented the protocol from examples sent to me, not from a specification. No specification is available that I am aware of. |
Beta Was this translation helpful? Give feedback.
-
@terjeio any possibility to support cluster mode?
Lightburn has enabled cluster mode starting with version 1.2.02.
This eliminates issues with slow planner and allows rastering >20,000mm/min greyscale with smaller dot size which is likely 4x improvement.
Additional motivation is that lasers are now using compressed beams enabling smaller dot size and higher resolution.
The implementation is as follows...
S values for each dot colon delimited up tp 8 values per line.
In this case a Svalue is given for every dot at 0.06mm spacing.
G1 Y-0.48S0.875:0:0:0:0.875:0:0:0.875
G1 Y-0.18S0:0:0.875
G1 Y-0.24S0:0:0:0.875
I can test for you.
Thank you!
Beta Was this translation helpful? Give feedback.
All reactions