Capturing a pin remaining True for a certain period of time

More
24 Jul 2024 07:25 #305945 by mighty_mick
Hello folks. I have a pin in a hal component. This pin becomes True when a fault detected. I wanna make e-stop if this pin remains True for a period of time. The key thing is time here. Because when machine goes e-stop off state after estop-on state, the pin remains True for a while, but it is not a fault signal. It is only reset state of the device. After some time, it goes to False and starts to operation. If i evaulate this pin without any operation, i am not being able to make estop-off, because the signal is being True at that time, and machine is doing estop again.

According to this scenario, i need a hal component which gives True output if the input pin remains True for a period of time. I've used oneshot-edge components but they don't meet my demands. They act like when input pin gives the expected edge, they give output regardless of time of input pin. If there is no appropriate component in LinuxCNC, i am gonna develop intermediate hal component to do it. If you have a solution, plase share it with me. Thanks.

Berkay

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

More
24 Jul 2024 08:52 #305947 by rodw
First get familiar with the estop-latch component. Chain 2 together. One for the estop button and another for this component.
Then you could try a time delay component.

I that does not work out, write your own component that monitors the fault pin. When it changes state, set a flag (maybe call it error_set) then in another variable (error_time) accumulate the time its on for
if (error_set){
  error_time += fperiod;
  if (error_time > error_delay) 
    do something
  }
}
The following user(s) said Thank You: mighty_mick

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

More
24 Jul 2024 11:09 #305951 by Aciera
you might also want to have a look at the 'timedelay' component:
linuxcnc.org/docs/2.9/html/man/man9/timedelay.9.html
The following user(s) said Thank You: mighty_mick

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

More
24 Jul 2024 12:08 #305953 by mighty_mick
Thank you for your answer rodw.
I've developed my custom component in same logic and it works. My machine has an e stop chain which is formed by or-and-edge-oneshot components, and it works fine. For now, i don't think that i need a new estop chain. All i need to do is evaluate this pin status according to scenario given below and include it to my estop chain which formed by and-or-edge-oneshot component.

Delay component might be what i'm looking for. I am gonna try delay component first. Appreciated.

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

More
24 Jul 2024 12:42 #305957 by rodw
Remember, estop is an important safety feature. estop-latch is the correct method to implement it. Please watch this video

When using multiple instances, I find it best to sketch out a block diagram as it can be confusing
The following user(s) said Thank You: mighty_mick

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

More
24 Jul 2024 13:33 - 24 Jul 2024 13:35 #305958 by mighty_mick
When it comes to this topic, i am wondering about your ides about something.

There are a few features that i wanna add to my machine. This features include sending appropriate messages to the user via error channel. I am implementing this features in iocontrol component in source tree of LinuxCNC(by adding extra hal pins and controlling them in main loop), cross compiling it and integrating new execautable to target platform, which is my machine controller board. At very first times, i didn't want to change the iocontrol component but somehow i thought i need to change iocontrol component because actual software e-stop is depended on iocontrol pins (emc-enable-in, user-enable-out, ...). I was aware of doing it with hal configuration, like chain(might be yours or mine which is formed by or-and-oneshot components) but somehow i thought i need to add it to the core component because i am actually checking the motors to eliminate motor errors, and i don't want a delay in my system. Of course it can be done in hal layer via connections, but why would I do that when I can interfere with the core? (i mean iocontrol component.).

I've added extra lines to iocontrol component as input pins, and checked them in loop. If something is wrong, i am sending the appropriate messages via emcOperatorError like functions to error buffer and making user aware of what happened behind the scenes. These kind of stuff is a way to create a good user experience, this is my thought.

For this features, i've looked at ready-made component and i found message component. It didn't work well and i didn't research the reason. After that, i've decided to compile the iocontrol component again and integrate features into it.

What do you think about my solution? is it appropriate to change the iocontrol component to implement features like these? E-stop safety is very important, you are absolutely right. The reason that i did it in iocontrol component is, i don't want delays. When a motor stops, i don't want a thread gets the value and sends it to the other connection and the iocontrol component gets the command and makes e-stop. The thing i really want is if something critical happened, let iocontrol component handle it.

I would apprecaite if you share your ideas, recommendations with me, thank you again. I am gonna watch your video.

Thanks.
Last edit: 24 Jul 2024 13:35 by mighty_mick.

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

More
24 Jul 2024 14:14 #305961 by Aciera

I was aware of doing it with hal configuration, like chain(might be yours or mine which is formed by or-and-oneshot components) but somehow i thought i need to add it to the core component because i am actually checking the motors to eliminate motor errors, and i don't want a delay in my system.


Note that 'iocontrol' is non-realtime:
linuxcnc.org/docs/2.9/html/man/man1/iocontrol.1.html
The following user(s) said Thank You: mighty_mick

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

More
24 Jul 2024 14:21 #305962 by mighty_mick
Yes, i get it. But i think it is still better than evaluating fault via other component and connecting them in hal layer.

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

Time to create page: 0.101 seconds
Powered by Kunena Forum