-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion: Always trigger State change on boot/reset #45
Comments
It might even be useful to have a STATE_BOOT or STATE_RESET flag (or both?). |
I'll see if I can add this without too many changes. You may also handle this locally in your plugin, see below.
These events are already trappable, the plugin init function is called once during boot and you can subscribe to reset events by adding a function to the |
Thanks, I'll check that out. Another thought about entry points. I'm still getting familiar with the code but I want to be able to flash the light for certain states, like ALARM. To do this in a non-blocking way I need to loop, but with event driven call backs I can't be assured that I'll be called in a reliable interval. For now I switched the flashing code in to the Report update callback, but that only works when the sender is connected and reliably asking for updates. Granted, this is the expected action and most senders comply, but the intervals vary. And the current stable/official release of CNCjs stops querying during ALARM states (which is likely not the intended/desired situation, but it is what it is) which interferes with the loop. Would it be possible to have an entry point at the end of the main loop that is triggered not by an event but by the the end of the loop being reached in addition to the more classical trigger events already present? |
I have a couple of examples in the pipeline, one is a blinky:
|
Excellent, this is exactly what I was looking for. Is this available today or in your "to be committed in the near future" stack? |
Here is what I am doing for now for the flashing portion. Is there a HAL call that will return the current alarm sub-code? I haven't been able to find one yet. Also, is there an example available of reading the spindle state via the hal.spindle.get_state call? Spindle on is one of the key things I want track. I've not tried to optimize the code yet (and I'm a relative novice), still trying to work out my core logic. I am hoping to be able to do things like: for a limit switch triggered alarm, flash red but add a fast pulse of an axis colour to the sequence, so you get a pulse of blue for Z, green for Y and red for X sensors. I've just got to figure out how to extract those details from the hal calls.
|
Your example works great. I'm going to move my code over to that callback. |
Found this too: (!(hal.spindle.get_state().on)) |
More examples were comitted yesterday.
There is no call, you can read the alarm code from
You can find one in grbl/report.c: Line 1156 in 2068165
Lines 1249 to 1251 in 2068165
You can also chain your code into the HAL entry point so you do not need to poll. See the plasma plugin for how to do that. Note that some function pointers are reset on settings changes,
Chaining in your own code into the HAL is in a way the same as subscribing to events, you can do all kinds of fancy stuff with that. Check out the code in the provided plugins for ideas...
A tip: polling for everything in the |
Thank you for the excellent feedback and all your work and deep thought on this project. The more I learn about how you have laid it out the more impressed I am with the structure and extensibility. Great job! |
Question regarding:
Is that an elegant way of saying "Only execute the hal.port.digital_out(port) call if the state is == STATE_HOLD? If so, could you have multiple of these in a row and they would almost act like a chain of if statements or a case statement? I hadn't realized you could put a test inside the function call, that is very helpful. |
No - it is a way to turn the output on or off with a single call on a state change. You can also write the hal.port.digital_out() call like this:
or like this: The last one is useful when the parameter value is something else than a boolean.
It depends, it will result in a bit of overhead since the function call will always be executed.
You can even use a function call as a parameter as long as it returns the correct type. No need to use a temp variable. An example: |
I forgot this one you mentioned above:
This can be written like this (most will do so?):
This is neat trick if only one element in a struct/union return value needs to be referenced. Again, no need for the temp variable. |
That is a very neat trick. These are all great details. All the tips are very much appreciated. I'm going to annotate my plugin extensively. I'd love to get your thoughts/code review of it when I'm ready to share. |
I am working on status lights for my machine and if the machine comes up in STATE_IDLE, it does not appear to fire the onStateChanged event.
However, if it comes up in STATE_ALARM (homing required) it does fire. It would be good to fire a state change during boot and reset events, so anything chained to that trigger has a chance to perform functions at boot/reset.
The text was updated successfully, but these errors were encountered: