Advanced Search

I’m attaching the files.

GennadijSpb wrote:

... but if you also move the X axis, the machine goes into error mode due to exceeding the Z limit.

That does not seem right, and may be caused by errors in the hal/ini files, so upload the config files here.

rodw wrote:

I'm sorry Tommy, but none of those 20 machines you retrofitted are compliant in today's safety concious world.

Oh hell....
YES, they are Rod, and you know that for sure as you have read everything i did here, but still you have to protect your convoluted ways by demeaning me and my work.
Yet, you did not read what STO actually does and the explicit warnings that go with it.
-
Rod, i will not continue this discussion any further, please refrain from tainting topics and only reply with actual helpful posts, as you often and for a long time did. Thank you.

It wasn’t fully fixed, but there’s some progress. Now the machine finds metal and passes the test normally in the home position and if you only move the Y axis, but if you also move the X axis, the machine goes into error mode due to exceeding the Z limit. What information should be attached? I have a PC with an AMD Athlon 3000G, 8 GB of RAM, an LPT‑PCI‑e board, and an LPT‑mach3 board; it’s powered via USB from the same PC and from an external 24 V power supply. All the sensors are inductive, except for the metal detection sensor; there, an NPN inductive sensor is used, which activates a relay, and the signal is then sent to the board via the relay. The metal detection sensor does not touch the metal directly; it is mounted on a movable, spring‑loaded plastic platform, and when it shifts, the sensor is triggered.

Actually, to be compliant for safety, a machine cannot depend on LinuxCNC to manage the estop. The compliant external safety circuit should be advising LinuxCNC when the an environment is safe via the iocontrol pins. That's how I have set up my last few machines.

And yes, your 15 tonne machine is a perfect case to adopt modern hardware. The servo drive needs to have a Safe Torque Off  (STO) input triggered by the redundant safety circuit so the servos are safely brought to a halt. In an ethercat environment, there is specific modules to manage this. To your Beckhoff EK1100 coupler you need to add a EL6900 safety PLC and a EL1904 that contains 4 compliant safe inputs. In the absence of STO, You can place two force guided relays in series to trigger the normal servo enable/disable. Siemens make  a 5 pole force guided relay and two of these would allow compliant shutdown of 5 servos (4 axis plus spindle) But you  would also need 2 more single pole force guided relays to fire the signal back to LinuxCNC's iocontrol to tell the controller an estop situation existed.

I'm sorry Tommy, but none of those 20 machines you retrofitted are compliant in today's safety concious world.

Dear PCW,
Again many thanks for helping out. This morning (before work...) I quickly cross checked the label and you are right: I unintentionally bought/received a 7i85S rather than a "normal" 7i85....  . This evening I will order a correct 7i85 replacement. My excuses for bothering the forum with such a beginners mistake, yet I am very glad I received this hint as it would probably had cost me many more days (in frustration) to find it out by myself.
Cheers,
Henk

If your machine has a single or more e-stops wired in series, and no other safety stuff >>>
>>>NO ROD, he does not need or should use e-stop latch.<<<
Having said that, it is nice to learn to use it, and it does what is supposed to do perfectly, but the built in simple e-stop works perfectly fine for simple safety e-stop, as proven by over 20 industrial machines i have retrofitted and having to use e-stop latch on two of them, some over 15 ton heavy.
-
E-stop is extremely important on many machines, on some it is just a nuisance, so not something you go around telling people "just use e-stop latch" and everything is fine.
On machines with brushed DC servos, that e-stop must be wired to "extreme limits" switches, not the same switches the machine uses as limits, so in case a MOS-FET/Transistor shorts and the motor goes full speed, the normal limits will do nothing, hence another set of limits wired to e-stop that cuts all power to servo drives and engages brakes if any.

I'm not worried about the DRO at this point - the widget rules are accomplishing what I want -  and I understand I'm working on an edge-case.

My intent now is to add LED's to the user sidebar tab, not circle back and mess with the DRO again.

I'll try it again without saving the probe_basic.ui file and see what happens.

EDIT

I just did an update/upgrade and managed to overwrite everything, since I was 'just fiddling around' I didn't bother making a copy of the PB config folder.  ARGH.

I'll have another go tomorrow.

you should not be saving the probe basic ui file only the files from the config folder. however, the main probe basic ui must be opened first to load the qtpyvcp widgets correctly. you can open it but not save it, only save the config user files. each one must be saved and then close designer and reopen for the next that should avoid the call for the qrc file which is located in the usr/python3/probe_basic system wide directory. you really should never have to go into that for this work.

the dro ui's like i said above have a timer that prevents them currently from registering the hal widgets on initial startup. I was too tired to mess with it tonight, but will have aquick look in the morning to see if its something simple. i know i had to add the timer to prevent other issues i was dealing with from loading multiple ui files so i make no promises. you may need to add the led's to the sidebar tab or something which shouldn't have any issues as demonstrated previously above.

Once your drives are connected with LinuxCNC, it won't care if you have Mesa cards or ethercat.
Ethercat may be more complex to install 

Ok, HalLedIndicator is now showing up in halshow.

Every time I tried to edit probe_basic.ui I couldn't save it due to permissions.  And trying 'sudo editvcp probe_basic' resulted in an error before opening.

Had to

• make a copy of probe_basic.ui and probe_basic.qrc
• paste copy in some non-root folder
• open sudo -thunar and rename the original
• open the copy in vcp
• open the user_tab.ui file and edit/save both ui files
• using sudo-thunar paste the probe_basic.ui & .qrc file copies back in to the python3/dist-packages/probe_basic folder.

I suspect my earlier failure is that I didn't have probe_basic.ui open, or the right .qrc file in the right place.

The user tab is not showing up on the screen (see attached), but at least I've made some progress.

try creating a config using lcec_configgen

so the dro's were not really meant to be customized in that manner so they went last in the loading sequence using a timer to stop any conflicts during load, that being the case the hal widgets do not get registered for the dro ui's only for the usertab uis.. i will see if there is some magic i can do to include the dro's and post back when i have an answer on it!

tietouwa wrote:

Is simply improving heat dissipation enough, or are there other solutions? The N100 is too expensive.

No it was a fault in the kernel. There is nothing wrong with a J1900, I used one for years, its just the baytrail chipset.

Billy wrote:

Aside: I have not been able to find any documentation that really explains how ESTOP is expected to work?  I'm unclear on if I should work with estop_latch or not?  The estop_latch documentation is also pretty thin and does not appear to include any examples for either simple or complex configurations?
 

Yes, you should use estop-latch if you have an external estop button (or a safety relay but that's another story). Its pretty well described in the man page and there was a hal tutorial about it on the forum.