Advanced Search

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

I answered on the github issue tracker, but you set number of steps with normal "setp" in the hal file.
The new Enable PDO/Pin should be connected to net x-enable, that way it only generates steps when the machine is "on".
Like soYou also have MaxAcceleration as a new PDO and the guideline is some 25% higher than ACCELERATION in the ini file.

if I'm working with tooltable, minimized the window and need to finish work, then I turn off the computer and tollyable file is corrupt

I understand this, I'm trying to explain something else. If the tooltable program did not complete correctly exit, then the tool file is corrupted. There is no backup. Backups must be made manually......

In general I would not use a step/dir drive with encoder feedback to LinuxCNC unless
this is a dual feedback system, that is for example a step/dir drive with local rotary
encoder and a separate linear encoder fed back to LinuxCNC. This way the high bandwidth
motor control loop is run locally and the lower bandwidth but higher high accuracy control
loop is run in LinuxCNC.

There are also noise issues when feeding drive connected encoders to LinuxCNC as the ground
reference of those encoders is often the negative motor power line. (At least in small DC powered drives)

sry for delay.

i have now the whole machine running with the original controller.

all works.. steppers,maindrive, all sensors and the spindleencoder.

in the next days i link up my raspberry pi 4 with a 7i92.
why the rasp? its easier for me instead a notebook.. i have the machine in my garage not in my basement...

if all works and linked to the mesa and is in my linuxcnc i came back.


parallel i would build a small model for the toolchanger to play in the apartment with the toolchanger carousel stuff.

thanks

I am a newbie and I not sure I am following this forum's rules.  First, is this the right place to ask Remora questions (I have read everything I could find for Remora documentation)?  I trying to build a RPI5 / SKR 1.3 system.  All of the Linuxcnc components compile cleanly *except* for the spi component which compiles but with about 15 warnings.  I pulled the latest off of github.   Any help appreciated and please let me know if I am using the forum incorrectly.  

How should (linear optical scale, 0.1 micron resolution) encoders be wired to a system using a LinuxCNC + Mesa 7i95T and ODrive Pro motor controllers for each axis? 

• Encoder wired in parallel to both Mesa and ODrive motor controller? (ground loop issues, etc?)
• Encoder wired only to Mesa with ODrive motor controller in open loop? (not recommended by ODrive)
• Encoder wired only to ODrive motor controller with LinuxCNC + Mesa in open loop? (loses the whole point of LinuxCNC and coordinated motion)
• Two encoders, one for each? (added cost and complexity)
• Something else?

ODrive recommends wiring the encoder to the ODrive as it is claimed to have much higher bandwidth and fidelity (8kHz) than the LinuxCNC system: discourse.odriverobotics.com/t/connectin...sa-vs-odrive/13208/9

In the future it may be possible for the ODrive to pass through / re-output the encoder readings via GPIO pins. This would seem to be an interesting option, but it is not currently implemented and it's not clear if there could be potential latency issues.

What is the recommendation from the LinuxCNC + Mesa perspective, and are there any pitfalls to watch out for?

I see that the EaserCAT-3000 board firmware has been updated on Github. As you mentioned earlier, you left out the step scale so it could be modified from the INI file. You also added enable pins, but I don't know how to use them. Could you explain these changes a little more?

Pretty sure LinuxCNC does not use Linux drivers for parallel port, it has it's own driver and all it needs is a memory address for it to work, but your results show strange addresses, so try 0 for address in the StepConf wizard, and if that does not work also try
1b80000000
and
0x1b80000000
Do reboot the RPI between tests.

Mazak can be seen on some of the videos here
www.youtube.com/@toma.cnc1/videos