Hi,

If anyone over this side of the pond wants to sell one of these please let me know. I am collecting parts for a passible project.
Thanks,

John

I’m attaching the files.

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.... image missing /media/kunena/emoticons/dizzy.png. 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

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.