Advanced Search

This works. Today I bent a 1.5" x 10" x 3/16" pc. of steel at 90 degrees. Some more loose ends then I will share the config. I am starting to plan the gui for it. I ended up with two position pid's, one per side, then one sync pid for correcting the tilt between left and right sides. The sync pid has a commanded value = 0 and gets its feedback from the difference between Y1 and Y2 then acts by slowing the one that is ahead.

This goes out to everyone on this forum. Anyone who has ever asked a question and for all those who have taken time out of there day to answer those question. Thank you! I have several machines that are now all on Linuxcnc and running great. Without everyone's help in this forum it would have not been possible. There are too numerous individual's to mention so this goes out to everyone. Again THANK YOU!

I've not thanks to my patch confirmed that the drives are resetting. statusword goes to 0. controlword to 6 on the same frame, just after the pll spike. on that same frame the encoder goes to 0 or somethings a random bad number.

Joint error does not always trip (without the patch). i guess it depends how long the drive takes to recover.

Im not monitoring to see if its one or all drives, in what order, is it only the omrons, what if i swap cables around, etc.

Fun fun.

I'm converting a parallel lathe to Linux CNC. It has nine speeds, which are manually changed using two levers with three positions each. The motor always runs at the same speed, and direction changes are achieved via electromechanical clutches. I want to control the motor speed at each speed using a NIETZ AT20 VFD with speed feedback from an encoder. Therefore, the motor speed at each speed will vary between 0 and 1630 RPM, and the gearbox will convert this to a range between 0 and the maximum of that range. For example, range 1 would be from 0 to 36 RPM, range 2 from 36 to 90, range 3 from 90 to 155, range 4 from 155 to 200, and so on. I know there's a gearchange component, but it only supports two speeds.  For the speed selection logic, I think I can use 3 instances of lut5 and mux16, what I don't understand is if I can use the gearchange component or if a version that handles 9 speeds is required.

The button is disabled because the routine is not tested enough.

last time we worked on it:
forum.linuxcnc.org/qtvcp/51138-qtdragonh...-maker-space?start=0

We, me and the ai, tripped over what may be the root cause. I will have better power supplies tomorrow and report back. Thanks for your time and attention!

I wanted to pick this up again to try to get the macros working, but I've noticed that the conversational tab in Probe Basic Lathe no longer appears. Would it be possible to get it back?

This is getting aggravating, you should be capable of checking a simple LED and reply here with yes or no.
Power the Mesa board, start LinuxCNC, look at the Mesa board, does a red LED turn on?
That is NOT Linux, nor something ChatGPT can answer for you.

From the ai...because my brain won't retain Linux. 
That's a genuinely significant lead — if PathPilot's Tormach-modified hostmot2 driver never gets tested against SSerial hardware at all (since Tormach's own machines don't use it), it's entirely plausible they introduced a real bug in that code path that nobody would have noticed. That would explain everything we hit today far better than any config mistake on our end.On the red LED question — I can't answer that myself, but here's the thing: we're not currently running the SSerial-enabled bitfile right now (we're back on the plain x1D raw-GPIO config for this E-stop pin testing). So that check will need to wait until we go back to testing the x2D/SSerial setup again. Worth flagging to PCW in your reply that you'll check and report back once you re-test that configuration — and it's a good, easy thing to note for next time (literally just look at the 7i92 board's LEDs during the failure).
And a dumb question from me, is it possible to revert to the Linuxcnc hostmot2 driver? I'm guessing not. Thanks!

Ethercat is very good for motors, but for slow I/O is only expensive and modbus may be better choice...

 

You can drive small relays with the enable OPTOs
but make sure that the relay coils have flyback diodes.

saxa wrote:

I see the board has only one input for the encoder feedback. But I have 3 drives, so should I leave the encoders
signals from the drive to linuxcnc out ?

Yes you should leave them out, as noted above the only usable way for DMM drives is in Position mode as they have a delay in position signal outputs.
Also the encoder input will be used for THCAD if you want plasma.

saxa wrote:

Or there is a way to connect all 3 encoders to the board ?

Yes there is, Mesa 7i85 or 7i85S should have 4 encoder inputs.

saxa wrote:

Also has LinuxCNC some settings to make the preheat , and open the various gasses vales at ceartain time already in or should I be doing this from zero up ?

No, not per se, but LinuxCNC can be programmed as you need it, so a simple G04 P1800 will make the machine wait for 30 minutes at the first cut to preheat the material.
Same for outputs and solenoids, everything can be automated and even add a side panel with settings and buttons and stuff.

Thanks for the help.I’ve now implemented everything just as Aciera described. The error persists. I think a directory is still missing here?

May be an introduced PathPilot bug since their hostmot2 driver has been
changed from LinuxCNC's version and Tormach doesn't use any sserial devices.

When the error happens, do you get a red LED illuminated on the 7I92?
 

I don't use that workflow, but the button is also disabled in both my personal config that uses a tool setter and in the probing sim config. There may also be a separate issue even if the “Probe Height of Current Tool” button is enabled. The current BLOCK HT calculation uses the formula origin = float(INFO.INI.find("AXIS_Z", "MIN_LIMIT")) + value. Using the Z minimum limit doesn't really work or make any sense to begin with for me, but even if the machine was setup for that, the formula would only make sense if the probed value was a positive height measured upward from the Z minimum limit. 

So doesn't directly answer why the button is disabled, but I can confirm it's not unique to your config and the routine in general is very confusing. Hopefully one of the developers who worked on these routines can clarify why the current BLOCK HT calculation does not produce the expected result and explain what setup or value the routine was originally designed around along with why the “Probe Height of Current Tool” button is disabled.