search

terjeio / grblHAL

This repo has moved to a new home https://github.com/grblHAL
232 stars 90 forks source link

STM32F1xx Odometers #103

Closed S2000Stefan closed 3 years ago

S2000Stefan commented 3 years ago

@S2000Stefan I have just committed an update adding the odometer option to the STM32 drivers. Note that I have not extensively tested this, it is a preview version. Enable in my_machine.h after copying the odometer plugin code to the project.

Many thanks for the very fast support. I do not dare to report this problem now. :) I have successfully installed the Odometers plugin as you can see on the following picture.

odometers

Then I did some tests on my desktop PC. The plugin worked wonderfully, recording the path of the individual axes and the time. Unfortunately I did not take a picture to prove this. After that I reset the recording with the system command $ODOMETERS=RST and installed the control chip in my machine. Since then I have to report that I can no longer get the plugin to record anything. See the picture above. I find this very strange. Maybe you can have a look at it again when you have time.

Another thing, since build 20201020 GrblHal no longer shows Alarm11 (Homing your machine) after startup, but IDLE although I set the hook at $22 Homing on startup required.

terjeio commented 3 years ago

Strange indeed - seems like the STM32F103 code somehow manages to corrupt the first byte in the EEPROM when the odometer plugin is installed. After that everything goes pear shaped... Looking into it now, hopefully I will be able to commit a fix soon.

S2000Stefan commented 3 years ago

I can report that it is now working again. I did a complete reset, reflashed and then ran a $RST=*. Even after a $ODOMETERS=RST command the plugin counts from the beginning again. Maybe it has hooked somewhere??? I am a bit speechless. I just wanted to tell you that you are not looking for something unnecessary. Sorry.

terjeio commented 3 years ago

There is something odd going on so it needs looking into. The other drivers I have tested the plugin with does not behave like this, thanks for reporting - nothing to be sorry for. Perhaps I should be sorry for not testing more...

S2000Stefan commented 3 years ago

Me again. :) Yeah, you're right. There's something weird going on. After disconnecting the controller from the pc and reconnecting it again, all recorded values of the odometer have disappeared. Also the plugin does not record anything again. I was glad to see that. ;) I like testing very much, which benefits me too. :)

terjeio commented 3 years ago

Memory corruption...

I increased the heap size a bit earlier to allow buffering 2K of EEPROM/FRAM - this is the likely the reason for failure. When I switched off USB and used serial communication via a FTDI breakout it started working as it should, same when I reduced the heap size for buffering of 1.5K instead of 2K of EEPROM/FRAM.

The USB stack uses quite a bit of RAM, nearly 6K of the 20K available, so one solution to get more RAM for plugins is to use serial communication via a FTDI breakout. Another is to upgrade to a F401 or F411 Blackpill, but note the pinout is a bit different so if a F103 specific CNC breakout is used this may not be possible.

I will run a long test overnight and do some more checks in the morning before commiting a fix. If successful then the odometer plugin should be usable with the F103. However, the limited amount of memory in the F103 means it is not well suited for adding plugins - especially so when using native USB communication.

S2000Stefan commented 3 years ago

When I switched off USB and used serial communication via a FTDI breakout it started working as it should,

This morning I also connected my controller to my desktop PC via UART for testing purposes. Unfortunately I cannot confirm that it works then. I had to reset the controller completely twice ($RST=*) before the odometer worked. It's also noticeable that you have to do some things twice before the controller works properly afterwards. Is this probably due to my uart interface? Afterwards I noticed that the spindle time was not counted. After disconnecting and reconnecting the controller the recording was gone.

Also the keyboard jogging does not work if $20=1. Then the error message "Jog traver exeeds maschinetravel....." appears This is for your information only.

Is there any advantage, besides more memory, to connect the device via UART, compared to the normal usb-connection?

terjeio commented 3 years ago

After disconnecting and reconnecting the controller the recording was gone.

This is due to an oversight by me, recording to FRAM will only be done after a $-setting is changed. It has nothing to do with the underlying RAM issue and will be fixed in the coming commit.

Is there any advantage, besides more memory, to connect the device via UART, compared to the normal usb-connection?

Less load on the processor as the UART code is simpler/leaner? The USB stack is from STM, I have not studied its inner workings and I do not know how much of the protocol is handled in hardware.

I have removed the UART code and buffers from compilation when USB is enabled, this gives me a bit more RAM to play with. With luck I'll soon commit an update that should work with the plugin.

S2000Stefan commented 3 years ago

I just did some more tests. I connected my controller via usb again.

I noticed, that you can switch on the odometer over $=20 1/0? After restarting the controller, the odometer does not work at first. But if you then either switch $20 on or off, you can use it to activate the odometer. Crazy. ;)

terjeio commented 3 years ago

Update comitted. No issues seen during testing today.

I had to reset the controller completely twice ($RST=*) before the odometer worked. It's also noticeable that you have to do some things twice before the controller works properly afterwards. Is this probably due to my uart interface?

This is likely due to the memory beeing corrupted. I have "hardened" the NVS support code a bit to avoid corrupted memory interfering with settings resets.

I noticed, that you can switch on the odometer over $=20 1/0?

Yep, this is due to me forgetting to inform plugins about configuration changes during startup (via the HAL)...

S2000Stefan commented 3 years ago

I'm sorry to inform you that after disconnecting the controller and reconnecting it the settings are not saved in the EEprom. I am sorry to bother you with this. ;)

S2000Stefan commented 3 years ago

I am very sorry, I forgot

define EEPROM_ENABLE 2 // I2C EEPROM support. Set to 1 for 24LC16(2K), 2 for larger sizes. Requires eeprom plugin.

to set to 2, many many sorry. Of course the settings are now saved permanently.

terjeio commented 3 years ago

And I am sorry I have to report a regression in the > 2K EEPROM plugin that will reset odometer data between restarts. Fix comitted.

I still have problems with the F103 driver and the EEPROM plugins when USB is enabled, sometimes it works - sometimes it fails. With UART enabled everything works fine. I am starting to wonder if my ST-Link programmer in combination with my new USB hub is causing this... The hub crashes randomly needing a power cycle to start working again. Will investigate more tomorrow.

terjeio commented 3 years ago

I give up on this - I have now tested extensively with 2K and 32K EEPROMs.

UART comms - both ok. USB comms - 2K fails but not always, 32K ok.

Do I have a cloned processor on my Redpill? Or is my I2C circuitry bad? The 2K is on a CNC BoosterPack, 32K on a small breakout board - both my designs.

The same CNC BoosterPack works with other processors I have tested this with so I would like to believe it is good.

With luck your setup will work perfectly fine - if not consider switching to another processor/board or use a FTDI breakout for UART comms.

S2000Stefan commented 3 years ago

Terjeio, calm down, everything will be fine. ;)

The whole thing was just meant as a nice gimmick, an option. Don't invest so much time in my thing. I'm using a 32kb chip and after some tests I couldn't find any abnormalities. Everything works as it should, the recording of the paths works great and after disconnecting and reconnecting the controller the data is still there. Everything is wonderful. The only thing I would like to mention is that the spindle running time is not recorded, which can be neglected in this case.

spindel

With luck your setup will work perfectly fine - if not consider switching to another processor/board or use a FTDI breakout for UART comms.

I will definitely think about this and look for and find a solution. Which board would you recommend from the connection and plugin possibilities?

terjeio commented 3 years ago

Terjeio, calm down, everything will be fine. ;)

I am completely calm ;-) Since there are many fake F103 chips out there I have decided not to add any further plugins to the driver - better to spend time on more capable processors.

Which board would you recommend from the connection and plugin possibilities?

The Teensy 4.1 breakout board by @phil-barrett is top class.

I am nearing completion of a breakout board design for STM32F4xx Nucleo-64 boards that will be fairly capable, you want to try that? 4-layer board, 4 axes, SD-card option, 2 aux inputs and outputs - 5V tolerant, I2C bus 3.3V or 5V selectable, DC spindle output, most inputs and outputs via optocouplers (there are 16 of them), Polulu or Trinamic SPI controlled drivers (TMC2130), external drivers via "dummy drivers", secondary UART for VFD spindle or MPG... I will soon create a github project for it, and get a small batch made:

bilde

The iMRXT1062 (Teensy 4) and STMF4xx drivers are the two I want to focus on for additional functionality.

S2000Stefan commented 3 years ago

I am nearing completion of a breakout board design for STM32F4xx Nucleo-64 boards that will be fairly capable, you want to try that?

If I am honest, I am actually very happy that my milling machine works as trouble-free with my controller as it does now, thanks to you. :+1: Of course, it would be an upgrade and a challenge to install a new controller, even then the future is guaranteed. But like they say, "Never change a running system". :-) But I will definitely think about your offer and contact you again if I decide positively. Thank you.

terjeio commented 3 years ago

The board mentioned in #105 could be used as a replacement going forward?

S2000Stefan commented 3 years ago

The board mentioned in #105 could be used as a replacement going forward?

Yes, the board seems to be a good replacement for my ST32F1xx, which is getting on in the days, is pin compatible, I'll order some. Shall I order one that I would send you for free? At least the driver of the ST32F4xx would have to be modified a little bit which would exceed my minimum programming abilities many times over. ;-)

terjeio commented 3 years ago

Shall I order one that I would send you for free?

If you do that I'll provide the driver for free ;-)

S2000Stefan commented 3 years ago

Very well then I order, but it will take some time because the boards come from china. Oh, I forgot, the boards are available with ST bootloader or Arduino bootloader which version do I have to order?