Compile Error Teensy Board Test branch / Spindle Error

[einencool]

Hi @terjeio I had a Problem with my spindle start up since the last days, and so I wanted to update my grblHal, but this is the Error, I get:

C:\Users\xxx\Documents\Arduino\libraries\grblHAL_Teensy4\src\i2c.c:97:13: warning: 'force_clock' defined but not used [-Wunused-function] static bool force_clock (i2c_hardware_t *hardware) ^ C:\Users\xxx\Documents\Arduino\libraries\grblHAL_Teensy4\src\encoder\encoder.c:113:13: warning: 'mpg_move_absolute' defined but not used [-Wunused-function] static bool mpg_move_absolute (sys_state_t state, axes_signals_t axes) ^ C:\Users\xxx\Documents\Arduino\libraries\grblHAL_Teensy4\src\grbl\grbllib.c: In function 'grbl_enter': C:\Users\xxx\Documents\Arduino\libraries\grblHAL_Teensy4\src\grbl\grbllib.c:159:21: error: 'grbl_hal_t {aka struct }' has no member named 'signals' driver_ok &= hal.signals.safety_door_ajar; ^ Fehler beim Kompilieren für das Board Teensy 4.1.

And one question, I got several times a "Alarm:1" when I'm spinning up the Spindle. But this error also occurs, when the Spindle and VFD are not connected to the machine. I tried different Sender Versions, but got several times "Alarm:1"

First I thought, that it was because of a faulty Endstop, but while the machine is standing, and also the VFD is unplugged, I got this error... The Console didn't show anything in "Verbose" Mode When I turn on the Spindle with M3 S12000 then the console says OK and then Alarm:1

Can you imagine, what could be the Problem?

[terjeio]

https://github.com/terjeio/grblHAL/blob/757beed6d960cbc860b775b7a987f53f5338bb02/grbl/grbllib.c#L156-L160

Can you change line 159 above to the following for a quick fix:

driver_ok &= hal.signals_cap.safety_door_ajar;

The warnings can be ignored, the bug is a regression from changes you have requested...

And one question, I got several times a "Alarm:1" when I'm spinning up the Spindle.

I assume this means it happens randomly. If you switch off hard limits ($21) does it still happen?

I tried different Sender Versions, but got several times "Alarm:1"

This has nothing to do with the sender, the alarm is raised by the controller.

[einencool]

Hello @terjeio The workaround fixed it, and I was able to compile it.

With $21=0 it works fine, but if I put in $21=1 again, then the issue occurs after some trials. But I don't know why, I fixed something with my endstops, but they only got a tighter spring, so that the alarm:1 will not raise so easy when I hammer the parts into the vise.

But now the problem occurs randomly...

:EDIT: This is when I filter out the RT-Commands:

:EDIT2: It seems, that I found a little Problem. The first trials I made, I also removed the relay for the spindle and everything was quite.

Now with the new Firmware, I observed, that the relay for my vac-cleaner started again. This we didn't hear on tha last trials...

But when I press the button for the vac-cleaner, sometimes it raises the problem "alarm:1" and I don't know why... Maybe it's a cheap switch, but this problem i hadn't got before... Maybe it can help you :-)

:EDIT3: It seems to be the port for the vac-cleaner. When I take the same relay for the Fan of my spindle, there is no problem, but when I put the relay into the holder for the vac-cleaner, then the problem occurs again after some tests. The cleaner is not installed, so there is no power flowing somewhere, it's only the power of the relay... Maybe the software debounce was disabled for some ports?

[terjeio]

Ok, it could be the relay coil making problems. Is the relay coil directly connected to the breakout board or is there any driver circuitry for it? Do you have a link to the datasheet for the relay?

[einencool]

The Relay is a Finder 40.61.9 12V It is connected with a socket to the Breakout Board. I have 5 of them connected and tested it with 3 different relays and got always the error on the Vacuum cleaner output.

The curious thing is that the problem occurs, even when there is NO LOAD on the relay.

And why does it throw the „alarm:1“ issue?

I tried to add two 1uF condensator to the endstops for my gantry (Y and B-Axis) because they are so sensitive. I added them between ground and the signal for Y and B Endstop directly to the screw terminal.

Is in the last weeks something changed to debouncing or can I activate it somewhere in the config? Sadly I‘m not able to test it in the next days, but maybe there was a change.

[terjeio]

The curious thing is that the problem occurs, even when there is NO LOAD on the relay.

The relay coil can generate noise, especially when switched off due to back emf. There is a snubber diode in the ULN2003 driver that should short that. Is the cable from the relay coil to the controller a long one? If so this could emit enough noise to trigger a limit input? You may try to connect a capacitor across the relay coil and, if the cable is long, a snubber diode too. These should be connected at the relay end of the cable.

Shorting limit inputs one by one at the controller end could help to find which one is triggering the alarm (if only one does).

Is in the last weeks something changed to debouncing or can I activate it somewhere in the config?

If so then not intentionally - and debouncing is enabled by default. I may have to check the code again and with a relay too - I believe I have a similar one at the workshop.

[einencool]

The Problem only occurs when the relay is switched ON I never had a problem while turning it OFF

The cable is around 10-15cm long, so I don't think that's very long ;-)

[phil-barrett]

Terje's suggestions are spot on. I was about to suggest exactly the same things. Also, a shielded cable might help.

It's not so much the length of the cable but where it runs. It is also possible the EMI is propagating through the ground on the board. If so the snubber diode and caps should help a lot.

[terjeio]

The cable is around 10-15cm long, so I don't think that's very long ;-)

Ok, can you try shorting the limit inputs one by one to see if all or just one triggers the issue? And I guess I have to fetch a relay from the workshop to see if I can replicate the problem here.

[einencool]

That's so funny, I never had 1 issue with this, and then I changed the springs in the endstops from 0,5 to 0.7mm thickness and updated the grblHal and BAM I can't get my machine back to work.. I didn't change any cables or the way they were mounted, shit EMI ;-)

I don't understand anything anymore... :-) I'll chnage the springs back, maybe there is a problem with them. It can't be the truth, that because of the springs in the Sensors, now the relay in the control panel makes the problems. But only one, and e.g. not he Fan that is also controlled by another relay when the spindle turns on...

Ok, so it seems that it's only my problem on the machine, so I'll close it here, thank you for your great support 👍

[terjeio]

I have now tested with a relay connected to the VAC output and one of the limit cables twisted around one of the relay cables to maximize interference. After switching the relay on/off over 50 times I have not been able to trigger an alarm.

As I mentioned earlier the next build gets a new command $LEV (for Last EVent) that outputs data about which switch that last triggered an action. I have added each switch set in separate fields so it will be easy to pinpoint the input(s) that triggered an alarm or event.

An example after triggering the X min limit switch:

[LASTEVENTS:,X,,,]

Format is: [LASTEVENTS:<control signals>,<min>,<max>,<min2>,<max2)]

Where <control signals> field may contain controls signal letters (H, S etc.) and the rest axis letters for the corresponding limit switches inputs.

[einencool]

Hello @terjeio Today I wanted to compile your latest Test-Version, but this time, these issues occur, maybe I'm doing something wrong, but I don't know what.

Arduino: 1.8.13 (Windows 10), TD: 1.53, Board: "Teensy 4.1, Serial, 600 MHz, Faster, German" C:\Users\xxx\Documents\Arduino\libraries\grblHAL_Teensy4\src\driver.c: In function 'limitsGetHomeState': C:\Users\xxx\Documents\Arduino\libraries\grblHAL_Teensy4\src\driver.c:983:16: error: 'axes_signals_t {aka union <anonymous>}' has no member named 'min' signals.min.mask = settings.limits.invert.mask; C:\Users\xxx\Documents\Arduino\libraries\grblHAL_Teensy4\src\driver.c:986:20: error: 'axes_signals_t {aka union <anonymous>}' has no member named 'min' signals.min.x = (LimitX.reg->DR & LimitX.bit) != 0; C:\Users\xxx\Documents\Arduino\libraries\grblHAL_Teensy4\src\driver.c:988:20: error: 'axes_signals_t {aka union <anonymous>}' has no member named 'min' signals.min.y = (LimitY.reg->DR & LimitY.bit) != 0; C:\Users\xxx\Documents\Arduino\libraries\grblHAL_Teensy4\src\driver.c:990:20: error: 'axes_signals_t {aka union <anonymous>}' has no member named 'min' signals.min.z = (LimitZ.reg->DR & LimitZ.bit) != 0; C:\Users\xxx\Documents\Arduino\libraries\grblHAL_Teensy4\src\driver.c:993:20: error: 'axes_signals_t {aka union <anonymous>}' has no member named 'min' signals.min.mask ^= settings.limits.invert.mask; C:\Users\xxx\Documents\Arduino\libraries\grblHAL_Teensy4\src\driver.c:998:15: error: 'axes_signals_t {aka union <anonymous>}' has no member named 'max' signals.max.mask = settings.limits.invert.mask; C:\Users\xxx\Documents\Arduino\libraries\grblHAL_Teensy4\src\driver.c:1006:20: error: 'axes_signals_t {aka union <anonymous>}' has no member named 'max' signals.max.y = (LimitY2.reg->DR & LimitY2.bit) != 0; C:\Users\xxx\Documents\Arduino\libraries\grblHAL_Teensy4\src\driver.c:1013:20: error: 'axes_signals_t {aka union <anonymous>}' has no member named 'max' signals.max.mask ^= settings.limits.invert.mask; C:\Users\xxx\Documents\Arduino\libraries\grblHAL_Teensy4\src\driver.c: In function 'limitsEnable': C:\Users\xxx\Documents\Arduino\libraries\grblHAL_Teensy4\src\driver.c:1042:56: warning: pointer type mismatch in conditional expression hal.homing.get_state = homing ? limitsGetHomeState : limitsGetState; C:\Users\xxx\Documents\Arduino\libraries\grblHAL_Teensy4\src\i2c.c:97:13: warning: 'force_clock' defined but not used [-Wunused-function] static bool force_clock (i2c_hardware_t *hardware) Fehler beim Kompilieren für das Board Teensy 4.1.

[terjeio]

Compiler error fixed now, affected auto squared axis builds only. Automated builds should be set up to avoid such errors, but not enough time for everything. Please report back if change is working as it should.

[einencool]

Fix seems to work,

now I made some tests with the new Version, and it seems, that the Relay for my Vac-Cleaner semms to be the point, but I don't know, where to search.

When using the $Lev command while the alar is raised, then nothing happens, and when I reset and Unlock, then only the message in the picture below is listed

I made several tests only to start the Vac-Cleaner with the switch that has it's own input on the Teensy Board. I didn't home or anything like that, just testing to raise the error.

When I add 1uF Cap (and an addittional 100 Ohm Resistor) it makes the behaiviour only worser...

[einencool]

One extra point, I tried to home my machine, but got always error Alarm:15.

And I was not able to square my gantry. Then I reuploaded the old Version from end of January and then everything works fine. So I think there is a bigger problem in the squaring Option now.

[terjeio]

When using the $Lev command while the alar is raised, then nothing happens

Some alarm states (1, 2, 10 & 17) blocks all commands except reset and status report requests. IMO most $-commands should be allowed, but that is a somewhat larger change that I am not yet ready to do. So you have to reset first as you did.

It is a bit intriguing that the $lev command does not show any limit switch triggered. This means there is a pulse on the input that is shorter that the debounce time. And this leads me to recheck debounce handling - it did not recheck the pin state before telling the core that a pin has been triggered. I am sorry about not checking that before.

You do have a problem with noise delivering pulse on a limit input, this could still cause random alarms? You may try to wrap the relay in tin foil and ground that if so. The pulse carries quite a bit of energy as it is enough to propagate through a optocoupler (with a NC switch it has switch off a LED long enough to change the output). It is IMO thus likely that your sensitive endstops somehow get triggered by the noise.

[einencool]

The wired thing is, that the relay itself doesn't seem to make the problem. If I unscrew all the cables from the relay holder, then I can switch the relay on and off as often as I can, but there is now issue.

When I put back on the wires or only one, than the problem seems to occur randomly. I also changed the cables, the relay, the relay holder and the "wall plug" for my vacuum cleaner, but nothing helps...

Now I just removed the relay and start the vacuum cleaner by hand, and everything is working without any problems.

Before flashing back, I checked the $Lev Status when I pushed one of the Y limits. And then it shows me H,,,Y,, or something in this direction...

Could be the "SE" alarm the problem?

And also I can't test it now anymore, because squaring the gantry doesn't work with this version like mentioned above

:edit Is the a option to get the message WHICH Y limit has been triggered? Because when testing the limits it tells me every time it was ONE of the two limit switches, but always only "Y"

[terjeio]

When I put back on the wires or only one, than the problem seems to occur randomly

So you get the problem with only one cable connected? No current flowing in the relay coil?

And also I can't test it now anymore, because squaring the gantry doesn't work with this version like mentioned above

So the fix I uploaded today does not work either?

Is the a option to get the message WHICH Y limit has been triggered?

$LEV does show that, from the changelog:

Added $LEV command for outputting report containing which limit or control switch(es) caused the last event.
Report format:
[LASTEVENTS:<control signals>,<min>,<max>,<min2>,<max2)]
Where <control signals> field may contain controls signal letters (H, S etc.) and the rest axis letters for the corresponding limit switches inputs.

In todays version I have added $LIM as well, this shows the current status of limit switches (not control signals) in the same format as $LEV.

[einencool]

Haven't seen, that you uploaded a new Version today.

I tried it right now, but the machine is absolutely not usable with this firmware....

I can't manually jog with the machine, because there is a massive delay between the command and then the "doing"

Then I tried to home the machine several times, but after some seconds, it drives the first time into the limit switch, pulls off, runs slowly for the second time and then it stops and raises alarm:3

Before that, I tried everything with the "end of January" Version, and there everything works fine...

So sadly, there seems to be a bit more damaged now :-(

When I put back on the wires or only one, than the problem seems to occur randomly

So you get the problem with only one cable connected? No current flowing in the relay coil?

Yes excactly, there is no load on the coil and it raises the error...

And also I can't test it now anymore, because squaring the gantry doesn't work with this version like mentioned above

So the fix I uploaded today does not work either?

Is the a option to get the message WHICH Y limit has been triggered?

$LEV does show that, from the changelog:

Added $LEV command for outputting report containing which limit or control switch(es) caused the last event.
Report format:
[LASTEVENTS:<control signals>,<min>,<max>,<min2>,<max2)]
Where <control signals> field may contain controls signal letters (H, S etc.) and the rest axis letters for the corresponding limit switches inputs.

In todays version I have added $LIM as well, this shows the current status of limit switches (not control signals) in the same format as $LEV.

[einencool]

Now I came back to the machine, and made one last test. With your newest Version, I'm really not able to work with the machine, Homing doesn't work, and jogging the machine is also not possible.

But I tried to raise the error with the relay, and it was for me not possible to raise the error again. I just installed back the relay and switched around 60-times, but the error doesn't come up.

Then I switched back to the Version from end of January, which is working well, except the Alarm Problem.

After that, I tried several times, and after maybe 5 or 6-times, then the alarm:1 raises again...

[terjeio]

With my machine simulator I use to test auto-squaring everything works well, as does my MSP432 mini mill (no auto squaring). So why jogging and homing has gone bad for you I do not understand. I will have to download from github myself to check. If ok I would like to get your compiled binary to test with, this can be found in the Windows temp-folder, from my machine:

I can also compile for you if you tell me what changes you make before compiling.

A good thing is that the relay error has gone, IMO this confirms that there is a short pulse on a limit pin that is gone when the debounce delay is over.

[einencool]

Sadly I'm now not at the machine, so I can only give you the changed files. When you need the hex file, I can give you maybe tomorrow.

my_machine.h.txt T41U5XBB_map.h.txt config.h.txt tool_change.c.txt

[einencool]

Just uploaded the file once again and the jogging is absolutely not usable... I didn't do more tests, because the machine didn't response to any commands, and I don't want to risk a crash with it. here is the Hex File from this build, and I also add the old version grblHAL_Teensy4_Upload.ino.hex-14.02.2021.txt grblHAL_Teensy4_Upload.ino.hex-31.01.2021.txt

Hope it can help you to find the problem, or do I have to make any "Resets" or something like this after flashing the Firmware?

[terjeio]

When I use your version there are indeed issues. I have no idea yet what is causing them, and I need a bit more time for debugging that. It could be settings related since you set defaults in config.h instead of using $-settings at run-time.

[terjeio]

It looks like it is related to #define ENABLE_SAFETY_DOOR_INPUT_PIN in config.h, if this is uncommented issues appear. Can you try with this line commented out and report back?

[einencool]

I hope on Thursday I'm able to test it, but sadly not before this day.

One additional point. Did you test homing with gantry support? This didn't work last time, maybe with this version

[terjeio]

I hope on Thursday I'm able to test it, but sadly not before this day.

That is ok with me.

I believe I have now narrowed it down to the prjc usb code, possibly a memory leak. So another thing to try is to switch to the arduino version in _mymachine.h by#define USB_SERIAL_CDC 1 and leaving the safety door enabled.

Did you test homing with gantry support?

You mean auto-squaring? If so then yes, but only with the simulator.

[einencool]

Ok, I‘ll try both on Thursday.

Did you test the Version from 12.Feb. Also with Gantry support with your Simulator? Because this Version didn‘t work on my machine. It was deforming my gantry every time with 0.2mm which was the maximum Value I entered before... I did 3 tests and was really surprised, that it failed every time.

Then I reuploaded the old Version and needed 4 times to „resquare“ the gantry

[terjeio]

Did you test the Version from 12.Feb. Also with Gantry support with your Simulator?

No, I have only tested with the 20210214 version. With that I see on my simulator that movement sometimes goes bad, just like jogging does. When testing with the changes mentioned above this does not happen any more.

[einencool]

Did now test with #define USB_SERIAL_CDC 1 but had the same problem as before while jogging It seems, that the machine runs for 3 seconds, stops for 3 seconds, runs 3 sec.........

One Point for your "great" clickbox I did a Reset and my configuration was overwritten, so my "Door State" was changed and I can't reconfigure it, because I don't come to the settings :-(

[einencool]

Uploaded Version with USB = 1 and Safety Door disabled, and it seems to work

And I also reinstalled the relay and tested around 60 times, and it seems also to work. But please give me the safety door back :-)

[einencool]

Also tested the Left Y Limit switch and now "ONLY" the Y shows up, not the "HSE" like the failure before...

The right Y-limit shows this:

[terjeio]

Did now test with #define USB_SERIAL_CDC 1 but had the same problem as before while jogging

That is strange, I have not been able to replicate with that setting. I'll try again, perhaps also with a UART <> USB converter.

But please give me the safety door back :-)

I will but I have to solve the problem first. If I remove some (random) settings from the new settings enumeration data structure it works as it should - very weird. So there is something that corrupts unrelated code or memory. Bad linker script? Since the Teensy4/Arduino framework does not support debugging in any meaningful way I'll have to try to replicate this on a debuggable processor?

Also tested the Left Y Limit switch and now "ONLY" the Y shows up, not the "HSE" like the failure before...

I do not believe this is related in any way.

[einencool]

But please give me the safety door back :-)

I will but I have to solve the problem first.

Just kidding :-)

But one question for the clickbox when starting your sender with an alarm. In which way you would like us to "change" settings, when we are not able to access them ;-) Because in this case I didn't know how to solve the problem, because I didn't find the option in the configs to reverse the signal for the door.

Another question, since it seems, that the new Version didn't raise the alarm from my relay, did you find a problem for debouncing, or could this also happen because of the problem with the Safety Door signal.

[phil-barrett]

You can always use a terminal app like putty or arduino console to change the $ settings.

[terjeio]

In which way you would like us to "change" settings, when we are not able to access them ;-)

By changing the input that causes the alarm. Usually by shorting the pin to ground.

You can always use a terminal app like putty or arduino console to change the $ settings.

Sorry, it is only nearly always. There are some states that blocks everything but a soft reset or a real time request. IIRC door state is one. Or not?

Another question, since it seems, that the new Version didn't raise the alarm from my relay, did you find a problem for debouncing

Yes I did find a problem, reported above.

There is something really weird going on, when I remove some text (constant character strings) it starts working as it should. The last one I tried was line 770 & 771 in encoder.c:

https://github.com/terjeio/grblHAL/blob/d8d890c62f071518bd5b4cae459ff183685c89ef/plugins/encoder/encoder.c#L770-L771

Can you try that too, or disable the encoder plugin to see if that changes the behaviour for you as well?

The weird part is that if I leave the string in the code and remove the call to the function that writes it out it still fails. Next step will be to take a look at the linker script to see if there are any clues there. IIRC static data such as strings is copied to RAM for faster access for the Teensy, and the amount of such data has been increased quite a bit with the latest changes to the settings subsystem - possibly breaking something in the startup code? Tomorrow...

[terjeio]

New version uploaded to the test branch.

I have flagged some constant data structures to keep them in flash (do not copy to RAM on startup) as this seems to be a viable workaround. If it is a bug report should be filed? If the linker is not able to output a good image IMO an error should be emitted by it and no output made...

[einencool]

I hope tomorrow I can make some tests. What Options should I use first with the new test branch? Standard Ones Like USB = 2 Enoder and Door enabled? Or what is your suggestion?

[terjeio]

What Options should I use first with the new test branch?

Start with those you want.

[einencool]

Alright, Then I take the settings like every time before :-)

[einencool]

Hello @terjeio , it seems, that your changes were correct. I've only uploaded your new branch with my standard settings, and everything was working correct. Also the safety door pin was first in the wrong direction, but the software started and I could change the state.

I tried to raise the alarm, but everything was working absolutely fine.

Thank you, and so I can close this issue (I hope so :-) )