Advanced Search

Hi,

To inform you, i recieved a mail from a Tormach software engineer.

The mail is longer and contributes to testing etc.
I told him to inform his boss, that there is still a legal issue to be solved. legal issue

Then it was quiet. He did not respond.
Does any one know if this legal issue is solved so there can be a collaboration started ?

but doesn't take the constraints of the individual axes into account.
This is correct. In the source code the trajectory path is used to calculate xyz coordinates.
There it doesn't apply any calculation to reduce any speed for x or y or z. So if Z maxvel is very low, it does not reduce
speed for z.

Will this be available for Debian 13 in the foreseeable future? Currently, there's an error message regarding the Python version, which requires Python3 (< 3.12) for the version in the repo. However, the minimum version for Debian 13 is 3.13. There's also a message stating that the key will no longer be valid within a year.

I give up, I've tried to explain, given links, but it appears a waste of time.

Not a goat but rather one of our Blackbelly sheep.

You still have coordinated motion even without position feedback to LinuxCNC
 

Is there some way to also provide encoder feedback to LinuxCNC to have coordinated motion? This is an important functionality for the application.

The machine will have multiple axes: 4 linear (3 + 1 redundant for gantry), 2 rotary, and 2 for a galvo (XY2-100) for a laser.

In that case I would run it open loop from LinuxCNC
(local closed loop to the drive)
 

The encoder (Ditron DC13), linear forcer (Parker ML18), and motor controller (ODrive Pro) were tested to work together for one axis.

The question is how to then integrate these components with LinuxCNC and Mesa 7i95T, specifically the wiring of the encoder?

The ODrive Pro drives the linear forcer and requires encoder feedback for proper control. The intention is to control the ODrive Pro with step/dir from the 7i95T. But it is unclear how to connect the encoder to satisfy the feedback requirements for both the ODrive Pro and the LinuxCNC coordinated motion and DRO.

Unless the scale was absolute or had commutation signals it's unlikely to be supported by most drives

Yea - when i started to look at the git, i can see its a 2 stage process.

1) the UI /variables
2) the code.

I can handle writing conversational as I have a few UI python to gcode scrips that use tkinter

too bad there is no template to follow for like a "hello world" macro test.

Ok, good to know about the recommendation on drives with local rotary encoders.

For linear forcers or brushless DC motors without local encoders, how should the independent linear encoder be wired, with respect to the motor controller and/or LinuxCNC+Mesa?

I do not recommend using the drives local rotary encoder as direct feedback to LinuxCNC.
It's possible but does not really confer any advantages. 

A system with a step/dir servo drive and an independent linear scale does have some advantages
in improving accuracy.

 

Do you mean you would not use step/dir drives with a single encoder at all with LinuxCNC, or that you do not recommend wiring a single encoder to both the motor control and LinuxCNC?

In this case, the drive is a linear forcer, so there is no rotary encoder and just one separate linear encoder. I am trying to decide how to wire it up.

I suggest adding a change, when the tooltable program starts, it makes a backup file of the main one, if the program starts and the file is damaged, it suggests opening the backup file