1. Forum
  3. Search

Advanced Search

Search Results (Searched for: )

  • thomaseg
  • thomaseg
17 Jul 2024 09:16
Replied by thomaseg on topic Safety relay and e-stop in LCNC?

Safety relay and e-stop in LCNC?

Category: Basic Configuration

Just to give a bit of "physical context", here is how it looks in "real life":
   
  • thomaseg
  • thomaseg
17 Jul 2024 09:10
Replied by thomaseg on topic Safety relay and e-stop in LCNC?

Safety relay and e-stop in LCNC?

Category: Basic Configuration

I'm using an ABB safety relay on my CNC converted mill (forum.linuxcnc.org/12-milling/50559-opti...mh50v-cnc-conversion) and I've set it up so that LinuxCNC feeds the e-stop circuit via an output on the Mesa board.

If LinuxCNC isn't up and running the e-stop cannot be reset. If the e-stop is triggered it can only be reset via my physical e-stop reset button, e-stop cannot be reset in software.

I'm using Delta B3 servos which have two different power connections on the servo drives, one connection for the logic section and one for the servo power section. The logic section remains powered all the time (per the Delta manual) but the servo power section is cut via contactors when an e-stop is triggered. The drives also have the e-stop signal connected to them so they can detect an e-stop and stop the servos using the built in brake resistor.

I really like the way you setup reacts. I cannot figure out if your safety relay can actually trip without LinuxCNC being on? From what i can see on your schematic the estop is wired to the drives + IO pin, but not the safety relay?

Your drives are better than mine. The way logic and power is seperated is very handy! Mine doesn't have that. Neither does my drives support external e-stop input since they run via EtherCAT.

pippin88 post=305449 userid=16922
Ha e you tried just setting it up in hal as an estop?

I have a simple estop button to LinuxCNC and when I reset the button LinuxCNC comes out of estop.
I still have to hit "power on" on LinuxCNC after reseting estop. This is generally recommended behaviour

Reseting estop should never result in immediate motion

Yeah, hitting "Power on" in LinucCNC is just fine, it makes good sense. And i agree that estop reset shouldn't restart motion, that is crucial!
I tried just simply setting the e-stop pin to emc-enable:
net estop lcec.0.DI03.din-0-not => iocontrol.0.emc-enable-in
...but this doesn't work and i also suspect that this isn't actually what i want :-)

rodw post=305452 userid=20660
There are two ways to do this. You can either run an external latch (which is a momentary switch) that resets the safety relay. In this case, you should connect a signal to a Linuxcnc input which is connected in hal to iocontrol.0.emc-enable-in This is the approach I took.
 


There is no need to press anything in Linuxcnc

I tried this simple approach with the above HAL-code, but this isn't working(at all)... maybe the emc-enable-in should be pulsed? I'm unsure how the internals of LinuxCNC works with these pins...

rodw post=305452 userid=20660
The other way is to  use iocontrol.0.user-request-enable instead of your external latch. Linuxcnc sends a pulse on this signal to act as the latch when the on screen estop is reset (S34 in the diagram).
When I researched this, this was compliant provided you isolated Linuxcnc (your controller) with redundant relays (K3 & K4). These needed to be force guided relays where a non conducting pin is forced between the contacts when they are triggered to ensure the contacts cannot become welded closed.


I should have posted a diagram in my previous post, but better late than never. This is my safety circuit:
 
 
I'm starting to think that i have to change this. So instead of the resetbutton(S6) goes directly to the safety-relay it actually goes to LinuxCNC. Then LinuxCNC is the only on that can reset the safety relay, just like in Unlogics case mentioned above. The question is then if should have an additional latch inside LinuxCNC or how should i structure the HAL?

A whole other can of worms is that the drives are connected via EtherCAT and uses CIA402, so i need to manage their state when the estop is reset. I have to re-initialize them after a reset, i'm not even sure this is doable via HAL logic...
  • Caffink
  • Caffink
17 Jul 2024 09:03
Replied by Caffink on topic Help understanding fundamentals of linuxcnc

Help understanding fundamentals of linuxcnc

Category: General LinuxCNC Questions

I think you have two types of jogging mixed up.

gmoccapy can jog with a screen button/arrow like most GUis

This is quite different than using an external encoder


You are right, I seem to have them mixed up. 

After some more reading, I might have cleared up some of the confusion regarding the basic concept of linuxcnc(hopefully).

Linuxcnc, or more specifically HAL and hal-pins are based on abstractions of real world hardware. So what you are doing on Linuxcnc is making a "virtual PCB", and soldering "virtual" connections between the hal-pins with net commands.

(This is a simplification).
For instance. Lets say you want to make a X-button that makes a stepper motor move, and that stepper motor is connected to a Mesa board.
1)That X-button pin Outputs Bit type(True of false), based on if it is pressed or not
2)Mesa Board has an input pin that accepts Bit type.
3)Then you connect the X-button pin with Mesa Board input pin with "net command" i.e(fictional example):
net x-btn-move x.button-pin => Mesa.Board-pin
4) You don't necessarily need to know how the Mesa Board communicates with the stepper motor, you just need to know that X-button-pin has to be connected to Mesa-board-pin, in order for the stepper motor to move.

Is this thought process correct?
 
  • Cant do this anymore bye all
  • Cant do this anymore bye all's Avatar
17 Jul 2024 07:52
Replied by Cant do this anymore bye all on topic New and Working RTAI debs for 2.9

New and Working RTAI debs for 2.9

Category: Installing LinuxCNC

Compiling the kernel is easy, where the skill comes in is getting the config correct.
And be thankful it's not the 90's and you're not having to do it on a 486 with 16MB ram.

Joking aside, it's probably best to have one set of debs for the kernel from a known source. Debugging is going to be, I'd like to say easier, rather than having user built kernels that maybe a little different, due to a change in config. Or how gcc's mood was on that day.

After coming from Slackware in the last 4 or so years to debian\ubuntu and going thru "RPM Hell" back in Ye Olden Days, installing packages via debs is pure bliss. I don't want to think about how long it took to install gitlab on a Slackware 14.2 server, just about every dependency had to be compiled. On Ubuntu its a one liner.

Just a suggestion Rod, pin grub so it doesn't get updated. Because somewhere some how it will make someone cry when they go to update it on a UEFI system with an RTAI kernel.
Displaying 25126 - 25129 out of 25129 results.
  1. Forum
  3. Search
Time to create page: 0.505 seconds
Powered by Kunena Forum