Advanced Search

While waiting for Andrax’s view, IMHO for a generic CiA402 setup there’s no standard “homing started” bit, so I’d supervise it with two simple triggers/timers.

I’d start the overall homing timeout when the drive actually confirms Homing mode (6061 == 6). Then, when we assert the homing start (opmode-specific, e.g. the bit-4 flip after 6061 confirms), I’d start a short “start→motion” watchdog and look for real motion as proof (e.g. |6064 - pos0| > eps, or 606C > threshold).

andrax wrote:

@rodw Yes, I would have implemented it in the same way in a PLC. The only thing missing is the safety timer from start homing to axis in motion. Then the homing would be practically monitored. Regarding the axis jumping, you could set the feed rates to minimum after completion until Linuxcnc has synchronized.
 

Can you explain this timer? I would have thought you get the homing signal from linuxcnc, pass it on to the drive then  loop until bit 12 goes true keeping lcnc in sync.. I can't remember off the top of my head how we check that the homing request has actually stuck but I seem to remember we could do this too before doing the loop. Bit 13 will tell us if there is an error during homing.

I think after you upgrade your linuxcnc, you might want to build a compatible version of linuxcnc-ethercat
and check your settings
with your hardware generic is inevitable, it is not supported, performance will not be guaranteed. I should look at getting hardware that already has support from IGH
like intel igc or intel igb
but I never got eoe to work, so you are already ahead of me on that front, so I might be just blabbering nonsense...

Hakan wrote:

rodw, I kind of think of a structure like this

if drive ready
  if csp

  else if csv

  else if pv
...
  else if probing

  else if homing
     if homing_method == 1
     else if homing_method == 2
     else if homing_method == 37
        Do the torque homing. Although it doesn't seem to be standard
     

Keep track of what op-mode we were in last time so we recognize a transition
between op-modes. To deal with offsets and such things.

Great feedback I wasn't really happy with what came after the state machine but I've had to put this project down for a week or so and you forget everything when its so complex. 

Looby wrote:

I know that some contactors are mechanical so going higher amps increases service life and solid state contactors are heat limited but why would companies state that such a high overage is needed?

Frankly, I'm a bit puzzled where that 5-10x safety factor recommendation comes from. A quick google search shows me 1.25x and 1.5x safety factor recommendations. I tend to go for a 1.5x safety factor, in more extreme duty conditions I've done 2x or 3x. A big contactor killer is frequent start/stops. I can imagine 10x might be used in some special applications.

The 7I76EU is compatible with 7I76E hal/ini files, so you can
just select "7I76E" in pncconf.

If you have usb, you can update with Deb files

Run another update i think your on the faulty commit. Should be resolved now, stable is now 0.6.5

Does this value always needs to be equal to the min value? Please help, thanks.

Hello. 
I'm new in this form. I couldn't config my Mesa Card 7i76EU, the PncConf doesn't show the 7i76eu. I'm using Linux CNC 2.9.8. Thanks in advance.

The two 120v ins is more just because I think I will overload a single 120v outlet so trying to split the loads to different circuits. It SHOULDNT but really dont want to wire this whole thing and THEN find out. This is unfortunately a "mobile" setup that I have to load up and take to and from work as I cannot run a router like this in my apartment so I am also making some allowances for portability in this setup so both plugs will be detachable from the unit to ensure power safe if needing to work inside the box. All of this is going in a rolling road case... Yes I know sketchy sketchy sketchy but.... nah no buts I know its sketchy.

I know that some contactors are mechanical so going higher amps increases service life and solid state contactors are heat limited but why would companies state that such a high overage is needed?

I will have YangYang take a look after the holidays, thank you for testing.
We are on a Chinese new year brake for a couple of weeks.
I'm still working on Planner Type 2, will see what YangYang thinks after the holidays, hopefully Rob will also do some testing

Most contactors list a thermal current rating and an inductive current rating, if your load is less than those current ratings you're fine.
I usually use 30A contactors for 20A loads... just oversizing a bit for good measure.

Not sure about two power sources, are both going to the same box? I try to avoid that. It can cause accidents if someone disconnects one power source and starts working on it. If two power sources to one box is unavoidable, label the cover with a warning label stating the box is powered by more than one power source.

If the two 110V power inputs shown are going to separate boxes, I think it should be fine.
 

You maybe could check the lathe macros uo files using editvcp and fine the lathe macros in the probe basic widgets directory and verify the parsee widhet entry names correspond correctly with the macros being used. From a glance it appears they may not be the same.

github.com/kcjengr/probe_basic/tree/main...dgets/conversational

You need to make sure those variables are get ng from the ui to the subroutine at the top.

rodw wrote:

There is no need for a GUI to get involved with external hardware. Thats what halui is for.
When GUIs extendRod their scope, we get a mess with differing configs for no reason.

Rod, I use the Axis GUI as representing what the hardware controls on my Three axis mill have done and are doing. In particular when setting the tool offsets using the touch off gui buttons, If the X or Y axis instead of the z is selected, then the tool table gains an unexpected x or y offset. If you control the machine by the gui that's my lookout, but to move a big machine around you must use a pendant. I have mpg and three momentary buttons to select the axis for the mpg to drive. It is very easy for me to move the machine only with the pendant, and lastly touch down the z direction for work and tool touch off with the x still selected because my jog buttons are not reflected in the gui. Done it too many times.
But, today, I found the forum.linuxcnc.org/38-general-linuxcnc-q...ns/50151-axis-select  python script, and its transforming. The radio buttons move with the last jog axis selected, and I can stop worrying quite so much about stray tool table entries.