RT1020 driver

[Moffy]

Hello I have set up the repo as requested. I have managed to get the LPC1769 driver to compile in MCUExpresso, will have a think about configuring for the RT1020. Might use an example and clean out most code and put things like all the "fsl_..." drivers and CMSIS in their directories and work from there.

[terjeio]

Yeah, the error:7 doesn't seem like the best way to start comms

I have just updated the test branch to not output this when NVS is not available.

At some stage I will try to emulate the EEPROM with the external FLASH

I forgot about this processor not having onboard flash - it is sometimes hard to keep track of the details of all the variants I am working on/with...

[Moffy]

"I forgot about this processor not having onboard flash - it is sometimes hard to keep track of the details of all the variants I am working on/with..."

I know what you mean.

[Moffy]

You might be interested with my request to GRBL: https://github.com/gnea/grbl/issues/967 about numbering 'ok'. Seems they have got something in mind.

[Moffy]

Finally, after much painful searching and trial I have gotten the serial comms from Candle, (GRBL controller software using Qt), working reliably with my RT1021 controller. It seems there is some subtle difference in the way the NXP CDC VCOM works compared to an FTDI USB to Serial chip. Not all comms software works with it. It is possibly one of the pseudo signal levels, not the obvious ones, but other software such as Putty and the Arduino Serial Monitor work fine. Candle seemed to work, as long as you only connected once, after that every attempt failed. I trialed a number of solutions, but the one I liked most and suited Candle best was QextSerialPort. It was simply a matter of including the code in the Candle project and replacing the QSerialPort with the QextSerialPort, and voila working comms! It is very easy to use. If anyone has any knowledge as to what the difference between the NXP CDC VCOM and other devices I would like to know.

[Moffy]

Here is the modified Candle code. CandleQextSerialPort0.1.zip I compiled it using Qt mingw 5.15.2 32bit and am working my way through the warnings.

[LETARTARE]

Hello, I see that you used an old version of 'Qextserialport'. I changed version '1.2rc', to receive the notifications of appearance or disappearance of a serial port under Linux. You can consult 1.2rc on last commit. I compiled on 'Vista-32, Qt5.97' and 'Win7-64, Qt-5.12.2', and 'Leap-15.1-64, Qt-5.12.2' Good day.

[Moffy]

Thank you LETARTARE for the heads up, and some great software.

[Moffy]

I have moved the 'user_mcode_t' from 'grbl/gcode.h' to the driver part, a new header called 'usermcodes.h'(fancy name) so that they can be modified without having to touch the base 'grbl' code. Of course it needs to be included in 'gcode.h'. grblHALusb_serialcommsv0.65.zip

[Moffy]

I have updated the 'grbl' code to the latest used in 'grblHAL-test', and remembered/reconstructed grblHALusb_serialcommsv0.66.zip my modifications and it all seems to work. Yeah!

[terjeio]

Happy Holidays!

Great that your modifications are working!

I have moved the 'user_mcode_t' from 'grbl/gcode.h' to the driver part, a new header called 'usermcodes.h'(fancy name) so that they can be modified without having to touch the base 'grbl' code. Of course it needs to be included in 'gcode.h'.

This is not going to be merged with the master as it will be impossible for sender developers to keep up-to-date with definitions possibly spread all over the world.

What you should do is to add them to gcode.h while you are testing and later make a pull request so your additions can be merged with the master.

There are some changes coming to handling of user defined mcodes, the most important is allowing valueless parameter words. This means parameter validation has to be added to your code. For float parameters with no value provided the value will be set to NAN (Not A Number) and for integers all bits to 1. Use the isnan() function to check for NAN. I am also pondering a switch to a bitfield union for the value word flags in order improve readability:

if(*value_words.q && isnan(gc_block->values.q))
    state = Status_BadNumberFormat;

vs

if(bit_istrue(*value_words, bit(Word_Q)) && isnan(gc_block->values.q))
    state = Status_BadNumberFormat;

I'll check the assembly generated before doing this since there are some code like this that might be negatively affected:

bit_false(value_words, bit(Word_Q|Word_S|bit(Word_X)|bit(Word_Y)|bit(Word_Z)|bit(Word_H)));

However, for ARM processors it could well be that there is no performance/code size hit by changing this to:

value_words.q = value_words.s = value_words.x = value_words.y = value_words.z = value_words.h = 0;

[Moffy]

Happy New Year! I'll follow your recommendation about the user codes but it seems a shame to be modifying the base code for them seeing that they are a driver issue. You could consolidate all the codes into a single header in the driver side, that would stop the problem of 'all over the world' and keep the base freer of the driver code. But whatever you suggest I'll go along with. So the idea of the 'Status_BadNumberFormat' is so that you don't need a status bit to say you have received 'Word_Q' etc? Sounds good, as that is one less variable to deal with, and the number becomes its own logic detection, consolidation. I still have a remaining issue of choosing USB_serial or just rs-232 type serial. There are some compiler varaiables that need to be set at compilation time, so you have, at present, to recompile to choose one or the other. Is that an issue?

[terjeio]

I'll follow your recommendation about the user codes but it seems a shame to be modifying the base code for them seeing that they are a driver issue. You could consolidate all the codes into a single header in the driver side, that would stop the problem of 'all over the world' and keep the base freer of the driver code. But whatever you suggest I'll go along with.

Moving this to the driver side will only complicate matters as all drivers needs to be kept in sync. And plugins has user defined mcodes implemented too. It will be far easier to handle this in a single place. The same applies to settings, alarm and error enums that may be user defined as well.

So the idea of the 'Status_BadNumberFormat' is so that you don't need a status bit to say you have received 'Word_Q' etc? Sounds good, as that is one less variable to deal with, and the number becomes its own logic detection, consolidation.

If returning an error there is no need to "claim" a letter, you still have to do that by zeroing it when accepting the command. The change is that value validation will become the responsibility of the code implementing the mcode, not the core parser.

I still have a remaining issue of choosing USB_serial or just rs-232 type serial. There are some compiler varaiables that need to be set at compilation time, so you have, at present, to recompile to choose one or the other. Is that an issue?

Not sure what you mean by this. You can add code to dynamically switch between USB or UART mode if you wish so, perhaps by adding a $-setting? I prefer compile time selection as the UART serial stream may be used for MPG or ModBus comms. Or you may add one or more serial streams for that if you want run time selection between USB and UART mode.

[Moffy]

"Not sure what you mean by this. You can add code to dynamically switch between USB or UART mode if you wish so, perhaps by adding a $-setting? I prefer compile time selection as the UART serial stream may be used for MPG or ModBus comms. Or you may add one or more serial streams for that if you want run time selection between USB and UART mode." At present they are not compatible with one another, you get one or the other but not both. Haven't looked deeply into the issue, but there are a couple of project variables that differ. Hence you choose one at compile time based upon the project variables that are set/unset.

[terjeio]

Your code for setting up the HAL stream pointes seems strange to me, a mix of USB serial and UART serial calls?

Here is how I do it in the STM32F4xx driver:

https://github.com/terjeio/grblHAL/blob/9cfceba724c826d205c569580e61f1b34cee2397/drivers/STM32F4xx/Src/driver.c#L1424-L1440

Note that the latest test branch has changes to the way user mcodes are handled.

[Moffy]

So the fact that it is one or the other, chosen at compile time is not an issue as you do the same, compile either for serial or CDC.

[Moffy]

The RT1176 is out, fantastic chip which I would love to use but there are cost/technology issues:

1. BGA 289, need someone to assemble it.
2. Recommended 6 layer board, bit expensive.
3. Chip cost below 1000 is in the $15 to $20 USD. So all up it is a bit expensive. EmbeddedArtists have a board for around 55 Euros as an OEM module but again a little expensive.

I started work on a RT1021 module which wouldn't have SRAM but use those pins for extra I/O, which seems reasonable for an RT1021 application. But then I reconsidered the SEEED Arch Mix RT1052 board, but again it is the limited I/O which turned me away until I realised that the LCD interface doesn't have to be used for an LCD. It can be used for general I/O if desired with a suitable cable. So I have purchased a couple of boards from Mouser and plan to migrate the grblHAL to it. The board also has the advantage that it can be fairly easily integrated with the MCUXpresso development chain, with a few guides available. The experience gained on the RT1021 should help a LOT!

[Moffy]

The port to the Arch Mix is going very well, so similar to the RT1021. With the standard pinouts, I have all the pins for GRBL as well as SWD, USB, debug UART, SPI and I2C. The LCD interface, SDRAM and SDCard are the icing on the cake.

[terjeio]

The Arch Mix looks like a nice board and not too expensive, RT1176 is IMO an overkill for grblHAL unless you plan to add new functionality requiring a lot of RAM and Flash.

Do you run grblHAL under FreeRTOS on the Arch Mix?

Are you aware of the new grblHAL repository where each driver has its own subrepository and dependencies are linked in by the use of submodules?

[Moffy]

Yes, I agree the RT1176 is overkill, but it is so attractive because of its functionality. I was thinking of using it for audio also because it has ASRC (asynchronous rate converters) built in, but it is too expensive for GRBL. It is nice doing the rewrite as I can clean up some of the mess of the previous code. I had also noticed your new repository and I might work a little harder to make this version a bit more compatible with your framework. I only plan on writing for a usbSerial interface though, I will keep LPUART1 as a dedicated debug port. Not using FreeRTOS, it will be bare metal.

[Moffy]

I got my boards yesterday, they look really nice. I have finished the migration of the code from the RT1021 to the RT1052, but it is untested as yet. Designing my interface board between the Arch Mix and GRBL.

[Moffy]

Sorry for the delay but I have been working on my grblHAL board as well as the code. It took a while for me to get the toner transfer method to work for my DIY PCB. Here is the assembled board(missing 1 connector). It is going to be a 3 axis CNC controller based on grblHAL. It has the 20pin SWD port as well as on board EEPROM(I2C), an SPI port as well as the USB,Serial,LCD,Flash,SDCARD etc of the SEEED module.

[terjeio]

Sorry for the delay but I have been working on my grblHAL board as well as the code.

No problem, great that you are getting closer to a usable driver.

Are you aware of the new grblHAL repo? This is split in many sub-repos up making it easier for third party drivers like yours to just pull in the bits needed via submodules. No need to fork anything at all, just link in the required submodules into your driver repo. I recommend you update your driver to match this.

It took a while for me to get the toner transfer method to work for my DIY PCB.

Yeah, not easy. I switched to laser expose presensitized boards after a lot of toner transfer failures...

It is going to be a 3 axis CNC controller based on grblHAL.

Looks good, may I suggest to use optocouplers for limits and control signals? Safer for the processor and a lot more noise immune. And the price of the Arch Mix has come down too making it more attractive?

[Moffy]

Thanks for the advice, appreciate your interest. Regarding using optocouplers, that's a good idea, but at present this is only a rough prototype focused on mainly developing code for the Arch Mix, as well as my first real board so I've tended to keep things simple, but there is protection on the inputs and outputs in the form of series resistors and filter caps, so along with the internal diodes of the processor they provide a reasonable level of protection. I am close to trying to program the grblHAL onto the Arch Mix(it is a great board). Using an LPCLINKII debugger along with MCUExpresso and advice and code from: https://mcuoneclipse.com/2019/07/27/debug-and-execute-code-from-flash-on-the-seeed-arch-mix-nxp-i-mx-rt1052-board/comment-page-1/#comment-302856 I was able to program a simple blinking LED program. Now I have to sort out the differences between the Arch Mix SDRAM and the EVK1050 SDRAM and I should be good to go. So much detail, lots of little steps.

[Moffy]

Good news, I got the serial comms working from grblHAL on the Arch Mix.

[Moffy]

Terjeio What power and speed do you run the laser at to expose the presensitized boards?Also what is your spot focus size? Interested in the details as I also have a 4W blue laser diode on a planar cnc. It has pwm so I can adjust the power. Planned on coating the pcb with black paint and burning the isolation between tracks off, then etching. But haven't gotten around to it yet.

[terjeio]

I use a 100mW diode @ 70mA and around 240 mm/s rendering speed. No gcode, I render a 1200 dpi bitmap in a custom machine. Spot size is matching the 1200 dpi resolution which is ~20 micrometers.

[Moffy]

Wow, that is incredible, the detail is unbelievable! No wonder that you have left the toner transfer method behind. Terjeio, you should market this! It is far better than many of the commercial alternatives. What about hole drilling? Manual or CNC? My guess is CNC because the holes in your PCB all have the same tiny offset. By the way, I have tested the stepper timer code (using GPT1 and GPT2) and the spindle pwm (using FlexPWM4). Limits and Control are disabled at present, but the code is in place. Need to work my way through 'driver.c' to make sure everything works.

[terjeio]

you should market this!

Not easy, since it is a laser device regulatory compliance needs to established as a start...?

What about hole drilling? Manual or CNC?

CNC - and it is possible to load excellon drill files in ioSender to have them converted to gcode on-the-fly (only lightly tested).

By the way, I have tested the stepper timer code (using GPT1 and GPT2) and the spindle pwm (using FlexPWM4). Limits and Control are disabled at present, but the code is in place. Need to work my way through 'driver.c' to make sure everything works.

Ok, soon you will have a working driver then. A case for a Hackaday article?

[Moffy]

Not a bad idea, if only for the reason it would force me to document everything. Not a great lover of paper work. I have also tested the external EEPROM (24LC256) over I2C and that seems to be working also, but not the driver integration yet. P.S. If you make your acrylic box out of orange acrylic it will heavily attenuate the 405nm laser, and prevent dangerous reflections. I had a cover made for my 4w laser.

[Moffy]

Seem to have gotten the I2C/EEPROM mostly working, still a couple of niggling issues. I have to set the number of start up lines to 1 else I get an error:7, I hate that error. Probably something a little weird with the I2C/EEPROM code. Well I shall keep plugging away, first time I've used I2C.

[Moffy]

Well terjeio, I have ordered an SLD3235VF diode and housing, I already have a couple of CNC's, I might just give your direct UV to pcb exposure method a go.

[Moffy]

Finally a version of grblHAL for the Arch Mix: ArchMix_grblHAL_0.1.zip The EEPROM seems to be working, there is still some debug code lying around but the basic GRBL seems to be working, though I haven't done much testing apart from the stepper pins pulsing at the correct frequency. The EEPROM code has a delay after each page write, will need to fix that with something better.

[terjeio]

I see you are still compiling against an old core version. Please update to the latest version.

I've skimmed through your code and have some initial comments/hints.

driver.c:

//FIXME: I don't get it. systick needed for usb comms
// Interrupt handler for 1 ms interval timer
void systick_isr (void)
{
    /*if(!(--delay.ms))
    {
        // SYSTICK_DISABLE; // Disable systick timer
        NVIC_DisableIRQ(SysTick_IRQn);
        if(delay.callback)
        {
            delay.callback();
            delay.callback = NULL;
        }
    }*/
}

I suggest you rename this to SysTick_Handler and call the USB handler here:

// Interrupt handler for 1 ms interval timer
void SysTick_Handler(void)
{

   USB_Systick();

    if(delay.ms && !(--delay.ms))
    {
        if(delay.callback)
        {
            delay.callback();
            delay.callback = NULL;
        }
    }
}

This way core delays will work as they should. I also see you have at least two other ms delay functions. You can replace these with calls to hal.delay_ms(<delay>, NULL). The last parameter can be a pointer to a function, if so the hal.delay_ms call will return immediately and the function will be called when the delay expires. This is used by the core to disable the steppers after motion is complete, legacy Grbl blocks all interrupts during this delay - not good...

I suggest you move some of the peripheral initialisation in driver_init() to driver_setup(). I2C, comms (USB and/or serial) and the systick timer is the only ones needed there. When driver_setup() is called by the core settings has been loaded (or set to default values) - appropriate action can then be taken there.

Adding code in the settings_changed() function is important if settings changes by the user is to be acted upon immediately. If not provided a hard reset is required for them to take effect.

Serial.c:

A call to hal.stream.enqueue_realtime_command() is required on receiving a character for real-time processing to work, senders will not work without that.

Serial.c and usbSerial:

You have plenty of RAM so I see no reason why you want to share the rx and tx buffers. If not shared and USB is chosen as the master stream the serial port can then be used for modbus (spindle control) or for adding a MPG controller.

The latest core has moved the rxbackup buffer and associated functions to the core as these can be shared between streams.

_mymachine.h: Is missing, should be there to be consistent with other drivers. driver.h should normally not be edited by end users.

The EEPROM code has a delay after each page write, will need to fix that with something better.

It is possible to speed this up by watching the I2C signals, I just add a 5ms delay to avoid that complexcity. If using FRAM instead of EEPROM no delay is required.

[terjeio]

Well terjeio, I have ordered an SLD3235VF diode and housing, I already have a couple of CNC's, I might just give your direct UV to pcb exposure method a go.

Ok, tell me how it goes. A few have tried to make a similar machine, one by modifying a 3D printer - don't know how that worked out. He had problems with to much backlash due to the "print head" beeing too heavy for the acceleration and speeds involved...

[Moffy]

Wow, you are fast! I will look at your comments in depth and thanks for them. usbSerial is the only choice for serial comms at present, Serial.c gets the data to and from GRBL onto the ring buffers and usbSerial.c moves the data to and from the ring buffers to the USB port. Therefore in Serial.c there is no device specific code, all of that goes into usbSerial.c or if at a latter time uartSerial.c, then maybe revisit the buffer issue.

I have a laser machine that is quite light, but I don't think it is up to your 240mm/s speed, but I can adjust where needed.

[Moffy]

I think I have addressed all of the issues, let me know. Please find the updated code and some explanations. ArchMix_grblHAL_0.2.zip

grblHALArchMix: v0.2

A) Serial.c: "A call to hal.stream.enqueue_realtime_command() is required on receiving a character for real-time processing to work, senders will not work without that."

Answer: The code is included in usbSerial.c/USB_DeviceCdcAcmBulkOut. Each byte received by USB is checked.

usb_status_t USB_DeviceCdcAcmBulkOut(usb_device_handle handle, usb_device_endpoint_callback_message_struct_t message, void callbackParam) { usb_status_t error = kStatus_USB_Error; uint32_t i, next_head;

if ((1 == s_cdcVcom.attach) && (1 == s_cdcVcom.startTransactions))
{
    s_recvSize = message->length;

    for(i=0; i < s_recvSize; i++)
    {
        //Need to process all the received data and place it in the rxbuffer, receive ring buffer
        //If true then it is a realtime command and needs to be dropped.
        if((hal.stream.enqueue_realtime_command != NULL) && hal.stream.enqueue_realtime_command(s_currRecvBuf[i]))
            continue;

        next_head = (rxbuffer.head + 1) & (RX_BUFFER_SIZE - 1);

B) Systick has been modified to include the delay:

TimersISRs.c/ void SysTick_Handler(void) //Tested:OK { USB_Systick(); //For ms level delays in 'driver.c' systick_isr(); }

Which does the same as your recommendation but keeps my mods together, ISR with ISR's. By the way, since the Systick ISR is asynchronous with the call to delay_ms, the the first delay could be anything below and including 1 'ms'. Should I set up a seperate timer just for the 'ms' delays?

C) My_Machine.h has been reinserted.

D) I will try a 6ms delay because of the dodgy first ms. Seems to work.

E) I think I have done what you requested in moving the timer initialisation etc from 'driver_init' to 'driver_setup'.Makes more sense since 'settings' has been initialised.

[Moffy]

I have been working on the serial comms on the PC side. I've moved from Qt(didn't like the environment) back to Visual Studio C++(MFC), no managed code here! I tried for ages to get one of the many serial libraries I found to work, but they didn't. Using the events and overlap with serial comms is very complicated on Windows and error prone. So I wrote my own little library with the Rx and Tx in their own single, non overlapped, separate thread. When something is received it sends a message to the main window, using ring buffers to handle the transfer of data between the threads, thank you GRBL. It is very reliable and the comms on the SEEED Arch Mix is solid too. Much on the PC side to do but at least now I have solid comms.

[Moffy]

Tested the Arch Mix running grblHAL with ioSender, works fine as long as RTS is set in the config file.

[Moffy]

Finally making progress on the PC side of the controller software. It can load GCode files, draw them, and create a height map which it then communicates to the controller.

[terjeio]

The sender looks good, are you aiming at making it a generic sender or will it be limited to mainly PCB milling?

[Moffy]

It will be both generic and specific. It will have a general terminal window, with a command edit box, but it will also have the specifics necessary for height map z tracking. It will depend upon the GRBL 'command' and 'ok' response for comms. The program can also open Gerber files and produce an outline trace for PCB routing. I did that a few years back using geometric intersections, took a while to develop, but it is very fast and economical on memory. Now I am trying to simplify the workflow and remove unnecessary steps. I hope to get my laser diode soon, what sort of package did you use for heatsinking? and what was your lens combination, G4? Your help would be appreciated.

[Moffy]

The first picture shows the GRBL sender with a gcode file opened: The second picture shows a Gerber file opened and how it has traced the blue outline for milling operations. The outline can then be output as GCode. The board in the Gerber view is what I am using and developing the grblHAL software for the SEEED ArchMix.

[Moffy]

terjeio, I have my code compiled against the latest core-grbl of yours, could you please look it over and see if it is suitable to be combined with your github. I have included my user codes into gcode.h. Look forward to hearing back. ArchMixGRBLhal_LatestGrbl_210618.zip

[terjeio]

I hope to get my laser diode soon, what sort of package did you use for heatsinking? and what was your lens combination, G4?

Here is a private message I sent to somebody on Hackaday that may help:

"According to the schematic the diode is a SLD3235VF, but not sure it is that I am using now. Any 100mW 405nm diode in a TO-18 housing can be used? I bought mine from two different ebay sellers, can't remember which now. A quick search shows that SLD3235VF is still available from a number of ebay sellers. Search for "to-18 brass housing" to find a suitable housing and lens for it."

Have you added Excellon to gcode transform for drilling? ioSender has an implementation in C# that uses a canned cycle and supports slots by drilling overlapping holes.

I have my code compiled against the latest core-grbl of yours

Can you please change your own repo to use submodules and link the core (and any other submodules) back to the grblHAL repo? I will be a lot easier to find the changes then and easier for you to create a PR for the changes you want to merge.

As for the driver code I think I would rather link back to your repo than incorporate it into grblHAL, this as I do not have a board to test the code with and I am not too keen to take over maintenance if you abandon the project.

[Moffy]

Thanks for the details on the laser diode. I just ordered, before this, a new housing and lens and it sounds very similar to what you mention: a small rectangular brass housing with a lens. No I don't have Excellon support I have been struggling with basics. Any pointers would be appreciated. There is one outstanding issue, for me, about the github core pointing to your repo. I noticed that you upgraded the HAL from 8 to 9, not sure all that that involves, but I just corrected my code until it compiled without errors, probably not the best solution. To keep my code in sync I would need to know all the changes involved in a HAL upgrade, otherwise my code will go out of sync with your core and fail. Also, will my adding user M codes to gcode.h be an issue?

[terjeio]

No I don't have Excellon support I have been struggling with basics. Any pointers would be appreciated.

Code is here.

I noticed that you upgraded the HAL from 8 to 9, not sure all that that involves, but I just corrected my code until it compiled without errors, probably not the best solution.

Normally this is ok, I try to make changes backwards compatible. You may loose out on new features though, e.g. some plugins may refuse to initialize if optional function pointers are not set up. Here is a list of some recent changes to hal.h:

This is from the underlying svn repository, I can give you read access if you want to see in detail what I am up too... Github history can also be used but is not as detailed.

Also, I have just completed the first step writing documentation for the HAL structure, you can find it here.

Also, will my adding user M codes to gcode.h be an issue?

Yes and no? Some of those I have added are lifted from Marlin, IMO we should not add codes in conflict with those that might be relevant for CNC use. E.g. M106 and M107 are relevant for lasers - for smoke extraction fan. PRs for the core code should be made against the core repository as changes to that may affect other drivers.

[Moffy]

Thanks for the update. Read access would be good as the last change did brake some bits, literally. If you could give me a block of M codes, say 50, that would not conflict I would be happy to use those as they become symbolic. Again, thanks for all of your support, it is appreciated.

[terjeio]

If you add a comment with your email address I'll send a password. You can delete the comment or remove the address after adding it so that it does not become public.

If you could give me a block of M codes, say 50, that would not conflict I would be happy to use those as they become symbolic.

Sorry, it does not work that way - if you want to add M-codes that is to be defined in gcode.h either an implementation or specification should be available so that it can be added to other drivers or plugins by whoever wants to do that.

There are currently five M-codes assigned that is free to use for everybody for private purposes: UserMCode_Generic0- UserMCode_Generic4. Code using these should never be published and their underlying M-code assignments may change at any time.

For private use or development you may add M-codes by casting without touching gcode.h, I have done so for the Open PNP plugin - the M-Codes used there will be added later (after I have fixed some conflicts).

[Moffy]

I have added a logging feature to my grblHAL implementation of the iMXRT1052 SEEED Arch Mix board. The board has the ability to communicate each step and its time(10us resolution) while running GCode. It is effectively data logging itself while performing real time tasks. The data is communicated over the USB virtual serial connection, with each byte having the 0x80 bit set to distinguish it from normal GRBL traffic. On the PC side the data is separated into two streams based upon the 0x80 bit, and the logging data is saved to file, while the original GRBL traffic is handled normally.

USB Virtual Port When you configure a virtual serial port for USB, one of the parameters is the data rate. In the context of the USB implementation this is meaningless and has no impact on communication speed. I have previously run some tests on the USB virtual serial port of an iMXRT1021 board and managed to get a sustained transfer rate of around 30Mbytes/s when the port was configured for high speed, buffer size became important for this. So for the data logging communication the USB virtual serial port has a lot of bandwidth that can be used without interfering with normal operations. It is like having a data logger permanently attached to the GRBL controller with a simple 'M' code to turn it on or off. This gives the ability to check that everything is executing properly without having to machine anything. It will give the data necessary to show the path traversed but also the dynamics, velocity/acceleration, of that path.

Now I just have to write a program to interpret the data:)

[terjeio]

I have added a logging feature to my grblHAL implementation

Interesting, have you checked how this impacts step pulse jitter? I have had problems with that on some STM32 processors and had to reduce USB interrupt priority to lower than the step timers priority to get rid of that. I see you have posted this over at the gnea repo, none of the 8-bit grbl implementations I am aware of has native USB so adding this feature to those is not going to work (the tranfser rate is limited to the UART baud rate in the MCU).

FYI I am working a PCB for and expanding on the code for a CNC Machine Simulator, first prototype PCB made yesterday. It is based on a PSoC 5 with has the support for FPGA-like peripherals. Initially I wrote the code for verifying auto-squaring for ganged axes, but I want to expand it to support a range of other areas such all verifying all I/O (including auxillary I/O), ModBus VFD spindle simulation, DAC output for plasma THC simulation and ADC input for spindle PWM (combined with auxillary I/O outputs for spindle sync simulation).

The core of this is four hardware (FPGA based) up/down counters that keeps track of stepper pulses. Code could be added that uses these for a logging feature similar to yours? If so then the simulator could be used for logging for all versions of Grbl and grblHAL.

with a simple 'M' code to turn it on or off.

You should consider using a $ command instead? I prefer $-commands for features not likely to be used from gcode programs and thus might require CAM post-processor support.