Advanced Search

Yes, your scale uses 34 bits rather than just 26 bits so that string looks closer.
you need 24 bits of (non Gray code) position, 2 pad bits, 1 error and 1 warning bit
and 6 CRC bits

The hostmot2 manual page describes the format string components in the SSI section
 

I have the same drive with ethercat comm card and it works - gets to an OP state. Can you share full config? I can check for differences.

Thanks!

I think their wording 26 bit binary format means its not gray coded.

RLS LA11: 

 


"biss_chan_0=null%1bcrc%6fwarning%1berror%1bencoder%26e" I saw this in a forum post where a person posted he was using similar renishaw glass scale. Where is the information about the format string? man page for hm2 doesn't go into this much details. Also the string I mentioned above doesn't work for me, but the person in the forum said it his scale is working.

Unfortunately, a longer runtime has also shown that the servo thread has poor latency.
 

I have displayed the interrupts, but I cannot interpret the displayed values.
Maybe performance monitoring interrupts and machine check polls?
 

I have no doubts about the kernels, it's more a question of knowing how to update/change them.


I would like to use the parallel port for the first tests. In case I don't like the software after all.

 

I'm looking for a reliable and safe solution to manage homing with absolute encoders. The machine has to be homed once and reminds the home position even after power off and mechanical movents in powered off state. So clearly, I dont have to home on every power cycle. 
My homing is done in the servo drive itself and passes the data to linuxcnc. 

What I looking for is something like that:
- I would like to disable the hole homing process from HAL, and on power on, shows me the machine is already homed, all axis turn green. 

What is the best method to manage absolute homing anyway?

Thanks. 
 

Cristian_g wrote:

“linuxcnc-uspace” will also run on a standard Linux kernel for use as a simulator, but it should not be used to control hardware."

This can be used to control machines when using the RT-Preempt kernel, it can not be used to control machines when using normal "generic" kernel.
RTAI version is more for use with parallel port.

Hi, sorry for asking too many questions. In the linuxcnc downloads web page,there is this note";“linuxcnc-uspace” will also run on a standard Linux kernel for use as a simulator, but it should not be used to control hardware."
Does it mean that in order to actually run a machine, I have to use the “linuxcnc” with specific RTAI kernel?
Please let me know which package I have to download! Thank You! 

One other issue that I noted was the overlay that I have circled in yellow.

Not sure if that's just my setup or a legitimate bug?

Thanks Chris.

 

You can power the 7I78 via one of the step/dir connections,
but typically the 7I78 draws such little current (<100 ma) that
it makes  mores sense to power it via the FPGA cable.

I have a system 7i92+ 7i76 (on P2 connector of 7i92) +7i84 (connected to RS422 of 7i76).

I am using separate (not FPGA) 5V power for 7i76 TB3 pin 21,22 (W2 in right position).

Now, I want to add one 7i78 (on P1 connector of 7i92).

If I do not use FPGA power, how to power the 7i78?

Yeah, you cannot depend on probing the screws on the terminal blocks unless they are tight...

Yes, output with respect to field voltage common.

But, I am sorry, outputs are actually working. The issue was that I was measuring voltage on top of screws and those screws were loose causing loss of contact to the pins at bottom.

Did you measure the output relative to field voltage common (TB1 pin 1)?

Probably not relevant but If you have a 24V field voltage, why would you use a separate VIN?

 

Thank you turboss for the vtk mastery!  the latest updates are out in both the stable and develop version now so plotting and rotation wcs as well as multiple work offsets draw beautifully as expected! hige thank you Turboss!