What (hal pin?) tells me that spindle speed has changed? (Waiting for spindle)

More
15 May 2020 20:57 #167892 by cmorley
well theincluded realtime component near is usually used for this purpose.
but if you want to make something else (I assume you use version 2.7)

linuxcnc.org/docs/2.7/html/hal/comp.html

Please Log in or Create an account to join the conversation.

More
18 May 2020 11:13 #168136 by frogandspanner
As recommended, I am now working on a realtime component to check for a change in commanded spindle speed.

I am concerned about race conditions: I want my output pin assertion to be 'seen' by the part of linuxCNC that prevents non-G0 table feed if a signal is low (spindleatspeed). I had thought I might stretch the output from my component, either by building a time delay into my component (no race condition) or feeding it through the timedelay component (potential race condition).

I shall now wear my ignorance on my sleeve: I assume that servo thread components are called repeatedly, and in a sequence. What is that sequence - the relationship as in the hal file? If so, is the postgui hal sequence just appended to the sequence of the pre-gui hal components?

As you can see from the lack of clarity of the question, I am too ignorant of the topic to formulate a good question.

Please Log in or Create an account to join the conversation.

More
18 May 2020 11:27 #168139 by bbsr_5a
servo-tread is usually 1000times a second recalled

Please Log in or Create an account to join the conversation.

More
18 May 2020 11:38 #168141 by frogandspanner
It's the sequence of component call that I think is important to my problem, rather than the rate.

Also, what is the relative calling sequences of base-thread and servo-thread wibblets?

That last question is more for interest, as (I believe) my problem space is all within the servo thread.

Please Log in or Create an account to join the conversation.

More
18 May 2020 17:05 #168164 by frogandspanner
linuxcnc is now screwed up. If I issue thelinuxcnc command I get an immediate message

"linuxcnc
LINUXCNC - 2.7.15
error in background error handler:
too many nested evaluations (infinite loop?)
while executing
"::tcl::Bgerror {too many nested evaluations (infinite loop?)} {-code 1 -level 0 -errorcode NONE -errorinfo {too many nested evaluations (infinite loop..."
error in background error handler:
too many nested evaluations (infinite loop?)
while executing ..."

and the LinuxCNC Configuration Selector dialogue box pops up.

As, at this stage, I have not told linuxCNC what ini file to use, it must be to do with the configuration with the component I have installed. The component installation produced no errors.

What can I do to analyse the fault?

Tony

Please Log in or Create an account to join the conversation.

More
18 May 2020 18:23 #168175 by cmorley
components run in the sequence there are added (addf) to the thread.
IIRC base thread can/should interrupt servo thread.

Please Log in or Create an account to join the conversation.

More
18 May 2020 18:24 #168176 by cmorley

Please Log in or Create an account to join the conversation.

More
18 May 2020 18:41 #168177 by cmorley
About your race condition.
The best thing is for the input to your component to be evaluated before it and the output to be evaluated after.

This is not always possible and often not important.
For instance the motion component holds both the requested RPM and the pin for up-to-speed, so it's not possible to to be before and after.
but on a normal setup it will assert 1000th of a second later.

I'm curious why you didn't just make an 'actual speed' pin from your USB component and use near? It's better to know the actual speed then to guesstimate how much delay you need.

Please Log in or Create an account to join the conversation.

More
18 May 2020 19:18 #168179 by frogandspanner
Let me summarise what I think it is I want to do:

1) spindle.0.at-speed - (bit, in) Motion will pause until this pin is TRUE

2) This does not prevent feed when speed changes as there is a race condition between that which detects that the spindle is at the commanded speed and that which has commanded the speed change. The feedback is outwith the linuxcnc realtime loops.

3) Ideal solution: motion could assert a pin to indicate, to components within the realtime loops, that a speed changed was commanded.

4) I am not up to speed [bad pun intended] to change linuxCNC.

5) My proposed solution, using invaluable help from this forum: bodge a realtime component that pulses a pin when a speed change is commanded, with a pulse length sufficient to cope with the time the external feedback system takes. This then inhibits table feed.

So far I have built the realtime component, plugged it in with timdelay, and using the Hal Configuration tool in linuxCNC, checked that I get a suitably pulsed pin.

Please Log in or Create an account to join the conversation.

More
18 May 2020 19:22 #168180 by frogandspanner
Yes - I can select a config. It was at that point that it fell apart as something had crept into my config file and crapped. I fixed that, but I note that I still get those messages, and suspect I always have - but not noticed them.

In looking I note strange lines like:

"treeclose /usr/share/doc/linuxcnc/examples/sample-configs/by_machine/tormach"

Please Log in or Create an account to join the conversation.

Time to create page: 0.178 seconds
Powered by Kunena Forum