Due Board Safety Door problem about core HOT 23 CLOSED

In Board Tinyg Due I could not declare a pin for Safety Door, response "driver error" or something similar.

Pins for safety door and probe is not defined in the map file. Are there inputs on the board that could be used?

In generic, it only responds by hardware.

It is programmed like that, if hardware input is available the real time command is ignored.

I could not get it to the Parking position: it only stops the movements and the spindle.

Is your parking target position ($58) higher than the current Z-position when the safety door input is triggered? Default is at -5mm (machine position). And is your machine homed? If not the machine position is undefined and parking motion cannot be executed.

Note that grblHAL keeps track of homed status per axis and does not allow functions that requires it, Grbl only assumes that the machine is homed...

from core.

In config.h I have unchecked lines 331 to 335
In machine parameters it does not appear $ 58
I ran the Due from z = -20.
$ 22 = 0, I don't know if it influences.
And the result was what I commented on.

Note: With arduino Mega and grbl in the same condition also $ 22 = 0, Safety Door did work both hardware and current software (informs Door 0; Door 1, Door 3 depending on whether by soft, by hard or reset)
I choose to use board Tinyg2_due_map (I want to have rotary axes)

Little programming knowledge, as you will realize ...
Once it works for soft, I would like it to work also for hard (without canceling it as much as possible)

• ///////////////////////// ----
  I have many free pins.
  This is what happened to me when I copied from generic map
  #if SAFETY_DOOR_ENABLE
  #define SAFETY_DOOR_PORT PIOB
  #define SAFETY_DOOR_PIN 17
  #endif
  some major conflict occurred, grbl cannot communicate with PC (surprised by this result)
  By the way, I didn't know that just declaring the probe pin is not enough (it is not declared for this map).

from core.

In config.h I have unchecked lines 331 to 335

It is not neccesary since there are $settings for all. If you uncomment you have to reset settings if you change those after a previous settings reset and reflash. Use $RST=* to reset.

In machine parameters it does not appear $ 58

You have to enable parking in line 621 for that to appear, maybe this is the reason parking motion was not working for you?

Settings available for parking in ioSender (and from the command line) when line 621 is uncommented:

I choose to use board Tinyg2_due_map (I want to have rotary axes)

If you modify a board map and do not want it overwritten on updates copy it to my_machine_map.h and uncomment BOARD_MY_MACHINE in my_machine.h instead.

some major conflict occurred, grbl cannot communicate with PC (surprised by this result)

I am as well because it works when I test it here.

By the way, I didn't know that just declaring the probe pin is not enough (it is not declared for this map).

Should be enough. It is past midnight here so I am not going to test it until later. And tomorrow will be a very long and busy day...

from core.

Only for when you have time.
I have not been able to fix it.
$ 58 not listed.
$ 49 = 0
$ 62 = 0
Line 621 uncommented in config.h
I assume some mistake of mine.
I downloaded SAMX3E to my Github desktop
Will there be any action to download submodules?
Then copy the directory to arduino libraries. Only that.
Any error in my routes?
file name src instead of core I don't think that is the problem.
Greetings

from core.

Probe works, my mistake

from core.

It seems that it does not register safety door.
on the IoSender list after Homing is Probing, Safety door is not listed.
when I make it work for the first time, error 7 appears, will it be the reason for the conflict (eeprom)?

from core.

I have uploaded a binary for you to try. 6 axes, probe and safety door inputs enabled (see the $pins output for assignments), parking, OpenPNP and plasma enabled (plasma fails with error on startup as it should).

Why you are not able to create a successful binary I do not know - perhaps starting with a fresh download and/or delete the Arduino build folders in your Windows temp folder will help?

when I make it work for the first time, error 7 appears, will it be the reason for the conflict (eeprom)?

Changing the build configuration will often trigger this as the EEPROM layout may have been changed. This is likely to result in a checksum verification error that triggers an EEPROM reset, and thus an error 7 message.

from core.

Deleted temporary files. The problem continues. Is it my Due?
I have never uploaded a binary. I still can't find how on the web
(From Ide Arduino? Command line? I have atmel studio, never used). It will serve to check if it works correctly in my Due.
I will need to make additions (analog input pin for vacuum table and for ATC), unfortunately I will have to confirm without Safe Door for now. Hug.

from core.

Deleted temporary files. The problem continues. Is it my Due?

I've got no idea - I am no fan of the so-called Arduino IDE, perhaps something wrong with how it is set up or how you have imprted the library?

I have never uploaded a binary. I still can't find how on the web

I guess that is a "feature" that everything is hidden away by default...

By setting verbose output during upload via File > Preferences I see that the command line used for upload is this:

C:\Users\terjeio\AppData\Local\Arduino15\packages\arduino\tools\bossac\1.6.1-arduino/bossac.exe -i -d --port=COM6 -U false -e -w -v -b C:\Users\terjeio\AppData\Local\Temp\arduino_build_788054/grblHAL_Due_Upload.ino.bin -R

Running bossac.exe from a command window with the -b argument changed to point to the binary should work.

from core.

I have uploaded your binary, it seems to respond well:
It does not report error 7
Warns Door1:
Which pin is for door and which is for probe?

from core.

Which pin is for door and which is for probe?

See the $pins output.

from core.

It does not respond to any $, I suppose that Door blocks the orders: bcnc doest not respond; IoSender black screen and message: "close the door or exit?"

from core.

Ok, chicken - egg situation. IIRC door was the same as you tried with earlier (PB17?) and probe was PA3? Analog pins 8 and 6 in Arduino speak.

Note that according to the pin map graphics I have the TinyG board does not have safety door and probe inputs assigned so I am not going to change that map file...

from core.

I have reloaded with Arduino Ide.
If I enable Pin for Safety Door, it recognizes it.
I compare behavior with classic grb ,:
(I know I read it, but I couldn't find it again)
By Soft or by Hard, activate Safety Door. Msg Door: 2
If by Hard and keep the door open: Msg Door: 1
If not, door closed and stopped: Msg: 0
Perform the Parking movements
Resuming: Msg: 3
Wait for ~ command to resume, even with the door closed.
grblHal:
If I enable pin for safety Door, when opening the door it stops the movements and spindle. It does not raise to Z-5. When closing the door, it resumes without respecting waiting time or waiting for command ~.
Does not recognize sendhex symbol 84
They do show $ 41 .... $ 61
I have changed $ 41 = 0 to = 1 and $ 61 = 0 to = 1 with no result.
(Status is Door :2 immediately Door:1 , )OK
If I comment pin Safety Door, there is no $ 41 ... $ 61 (Safety Door in Io Sender)
in bCNC: it responds to sendhex 84. Stops movements and spindle, waits and resumes (there is no Parking) (buttons need to be modified)
In Io Sender it does not listen to Sendhex 84 if it is executing a movement order.

from core.

Wait for ~ command to resume, even with the door closed.

What a mess - either my understanding of english is bad or original Grbl code is commented in a misleading way...
Earlier I wrote a new state handler to replace the original spaghetti code which was very hard to understand (for me at least), I relied on my interpretation of the code comments when I did that. And I see now that I have made mistakes.

I believe I have now fixed the new state handler and in the process made the code easier to understand. I need some time to verify this so be patient... Or if you want to give a helping hand in testing I can upload the source (but I am not yet ready to commit it to github).

from core.

his english is poor, my english is null .... from spanish to english via google translator ....
I can gladly play a laboratory guinea pig and help verify the tests, I can wait a long time for it to work properly.
I found the behavior when changing $ 41 and $ 61 from 0 or 1 strange.
In which file can I see a list of meanings of $ numbers?
(I would also like to know what the Parking and Security orders are)
I also did not know about the $ pins command, it is useful.
Great job.
I am satisfied with the way grbl handles the traditional security gate (hardware does not override software, ~ command required to resume), I think it is good practice to copy as is to Hal.

from core.

Core (grbl folder) for testing uploaded.

In which file can I see a list of meanings of $ numbers?

You can use the $HELP SETTINGS command for all, $$=<n> for a particular one, just $<n> for the current value or $SED=<n> for a description. <n> is the settings number. New or changed settings are also listed in the wiki.

You can also list all settings in Grbl comma separated format for sender use with $ESG.

Noe that ioSender fetches settings (and other) information from the controller, it is thus always up to date...

from core.

I forgot that ioSender needs an update for handling the door states correctly, available from here.

from core.

Maybe this helps:
In my bCNC, to monitor while doing a job, I have added two fields to see the speed and rpm in real time.
With Mega and grbl, when sending the Door Safety signal, I see the following sequence:
1-stops axis movements
2-go up z
3-stops spindle
To send ~:
1-Rapid lowering z to z previous + 5.00mm
2-turn on spindle
3-wait set time (to reach rpm)
4-Continue
With Due and Hal, when opening door physical button:
1-It stops movements and spindle, the axes do not move, however F maintains its value instead of being 0.
With $ 61 = 1 and $ 41 = 0 (just to test, also with $ 41 = 2 or $ 41 = 4)
When closing the door:
-Turn on spindle, wait set time, and continue movements
But, if $ 41 = 1; 3; or 5 (values that take $ 41 choosing in Io Sender tab grbl setting / safetyDoor / Parking cycle options),
no waiting time, axes move and rpm = 0
And it never went to parking position

from core.

1-It stops movements and spindle, the axes do not move, however F maintains its value instead of being 0.

Is your machine homed when you try this? And is the Z-position (MPos) below the $58 parking target?
Grbl assumes the machine is homed, grblHAL requires it to be.

When my test machine is in the parking position the real-time report looks like this:

<Door:1|WPos:3.300,4.965,21.000|Bf:0,1023|FS:0,0|Pn:D>

Can you post what you get?

from core.

Tip: If you enable "Show text overlay" in the Settings: App tab in ioSender you can see both the work position (first line) and machine position (second line) in the 3D View:

If the machine is homed the "Home" button has a green background colour:

from core.

My error: homing was disabled.
Sorry for using too much of your time.
Excellent modifying and tuning parameter explanations from io sender
Can you add a field to modify timeout to resume?
Greetings

from core.

Can you add a field to modify timeout to resume?

Ok, added on todo list for next settings revision. For now change the delays in config.h and recompile.

from core.