Advanced Search

Moved to "driver boards" section.

npostma wrote:

• Move down quickly until probe touch
• Move up a bit

It might be better to probe up (to loss of contact) then slowly down again rather than do a maybe-too-long fixed-length move. 
 

thanks a lot Tommy,
i’m trying to control two servo drives (Modbus RTU) with a Mesa 7i76EU in LinuxCNC, but I can’t use Classic Ladder or PktUART

tuxcnc wrote:

But this is very bad idea to send encoder's index pulse by ethernet.
Let's make calculations.
3000 rpm and 1 ms base_thread is 18 degrees accuracy - not acceptable.

This is actually fine, and is how all the other encoders work (Mesa, Pico, software) 

The counts are cleared on the index. 
At the beginning of the execution thread the motion controller gets the _current_ position, which includes all counts since the index.
These are used to calculate the actual position in space of the index. 
It isn't even time-critical, what the controller gets is the position in space of the index. It would still be perfectly accurate even if the motor did several turns between the index reset and the data getting to the PC. 
 

Yes, there is almost certainly something that you can do in HAL to make this work. Do the drives / encoders provide an output to say that they are ready?

You could try enabling the encoders as soon as the machine is out of e-stop, and potentially add a delay in HAL that disables motion for a suitable time.

What needs turning on in what order to make it work?

I don't know much about EtherCAT but I would have expected most of the motor control to be located in the slave device, so that LinuxCNC can't make it run rough. (but I might be wrong)

Do the servos initially do the field orientation with hall sensors and then switch to the encoder? If so then it could be a dodgy hall sensor or hall sensor connection. (Motors will run rough if the commutation is wrong)

Have you looked at the sample config sim/axis/remap/rack-toolchange

You can run that as a simulator to see if it works like you want, and then look at the way it is done to adapt to your own needs.

It works by re-mapping M6 to call a G-code subroutine.

The 7I73 does not currently support any higher resolution  A-D modes,
(I think the issue was exceeded the total serial data available) but
one simple thing to try is to low-pass filter the 8 bit data from the 7I73
in hal before using it to control the spindle speed.

If the flicker is greater than 1 LSB it may also be that you are picking
up some noise in the potentiometer wiper line. You could reduce this
by adding a small (say 1 uF) capacitor from the potentiometer wiper
terminal to 7I73 GND.

I haven't seen it yet either but I haven't used it yet either

I see, the "-m" flag makes it write the pdos.
But what about the sdos? I don't see them coming over.

Use the latest version of mesaflash
github.com/LinuxCNC/mesaflash
Scroll down for info on how to install.

because of the strange licenses from siitool i will write my own in python

I believe I figured it out. I was looking at it the wrong way. I needed to set the max limit in the ini file and then set the offset to move the home position further into the grid. I'm not sure if this is the correct way of doing, it but it got me the desired result.
This image shows my new position in the preview grid. 

I'm sorry, I still don't get it.
Are you saying that 'G0 x0z0' moves the tool to the machine home position despite having set a work offset (ie the blue circle instead of the coordinate system) ?

Using  with a Mesa 7i76EU (IP ). Ping works, but:mesaflash --device 7i76eu --addr 192.168.1.121 --readhmid
Unsupported ethernet device 7I76EU at 192.168.1.121
No 7I96S board found
Also tried with IP  after moving jumper W14 up
mesaflash --device 7i76eu --addr 10.10.10.10 --readhmidIs the 7i76EU supported? How to fix "Unsupported device"?