Advanced Search

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"? 

And unless you disable SPI you can not use the SPI pins for GPIO in linuxcnc

The images are setup and no adding users to groups or messing around is needed.
Read the following thread and you'll find a link to GPIO info and a working example.
forum.linuxcnc.org/38-general-linuxcnc-q...official-images-only

The fact that it quit working after firing the torch suggest a grounding or EMI issue.

If communication work but you don't get motion, it may be they the step/dir 
output drivers have been damaged. One way to check this is to disconnect the
motor drive step/dir signals and measure the 7I96S step/dir output voltages

The step and direction output voltages should be in one state when the 7I96S card is 
first powered up, and in the opposite state when LinuxCNC is started. 

That is the output voltage should be very close to 5V in one state and very close to
0V in the other state.

If the voltage does not change or you get any voltage that not close to 0V or 5V, this
indicates damaged to the 7I96S step/dir outputs.