Advanced Search

M3 S10000 ; works, spindle starts and spins up
M5 ; works, spindle stops
G53 G1 F4000 Z-10 ; Spindle does not move and GCode interpreter seems to be hung!

Is spindle-at-speed true? if not, pretty sure this will hang waiting for spindle-at-speed to be true.

One advantage, If you have step/dir servos, returning the position information to LinuxCNC
allows LinuxCNC to monitor the actual following error during operation.

DELETED as i missed a crucial point so my reply was not correct.
See PCW's reply below

OK, so an update on this issue.
Tonight I had some time to isolate where the problem is happening, and I can bring it down to just a couple of commands.

I start up Linux CNC, toggle the CNC on and home it, this is my start point.

Now in the MDI window I type the following

G53 G1 F4000 Z-10 ; This works, carriage moves down 
G53 G1 F4000 Z0 ; This works, carriage moves up 

I can repeat the above multiple times, the carriage moves up and down as expected.

BUT, if I type the following (either after typing the above or after a clean start)

M3 S10000 ; works, spindle starts and spins up
M5 ; works, spindle stops
G53 G1 F4000 Z-10 ; Spindle does not move and GCode interpreter seems to be hung!

On the console I see the following output 

mdi_execute_hook: MDI command 'M5' done (remaining: 0)
Issuing EMC_TASK_PLAN_EXECUTE --      (  +509,+280,   +23,G53\032G1\032F4000\032Z-10,)
emcTaskPlanLevel() returned 0
NML_INTERP_LIST(0x55afd11daa60)::append(nml_msg_ptr{size=208,type=EMC_TRAJ_LINEAR_MOVE}) : list_size=1, line_number=0
emcTaskPlanExecute(G53 G1 F4000 Z-10) returned 0
emcTaskPlanLevel() returned 0
NML_INTERP_LIST(0x55afd11daa60)::get(): {size=208, type=EMC_TRAJ_LINEAR_MOVE}, list_size=0
emcTaskPlanLevel() returned 0
Issuing EMC_TRAJ_LINEAR_MOVE --      (  +220,+208,    +0,605.000000,400.000000,-10.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,    +2,25.000000,25.000000,750.000000,    +0,    -1,)

I've attached the full console output from the linuxcnc command 
 
 

Oh good, and oh .... i don't know....

Yes that is it, and sorry forgot to mention, read until Host Interface section.

Thanks for the reply. I have LinuxCNC installed on a computer now but I’m still waiting for the Mesa card to arrive (should be this week). When you wrote ‘Mesa manual’ do you mean the ‘7i96s Ethernet Step/Dir Motion control interface’ document? If so, I’ve read it but will admit to not fully understanding all of it (yet).

Oh! I thought feedback would be required for coordinated motion.

What are the limitations or benefits without/with encoder feedback to LinuxCNC+Mesa?

Yes, to have all servos/drives start acting on new data/position data at the same time.
For servos and drives you want distributed clock mode.

The following error in LinuxCNC with EtherCat is somewhat superficial.
If the drive offers a following error, use that, if possible.

Hi Mars,

Great to hear that you are giving Remora a try. Those are just warnings, and can be ignored.

Let see if I grasp the concept. You have an existing reed switch that detects that the support is in extended position and you like stop all axis from moving when switch is active.
1) Wire the reed switch to your mesa digital input.
2) Load the new revised .comp file
3) You may need the change operations by changing the state of pins. for example, trigger=1; to trigger=0; same for halt and reedsw.

Attached is revised the revised spinport.comp

I am not super familiar with ethercat, but I would think you'd want a shared glocal clock for all the servos if maximal accuracy of motion was your goal.

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.