Advanced Search

PCW wrote:

7I36 has encoder fault detection but is only for differential encoders

How did i miss this ?
Thank you.

The second example is compiled-out by
github.com/LinuxCNC/linuxcnc/blame/maste...s274ngc_pre.cc#L1542
(But I am not clear why, the commit message doesn't really say: github.com/LinuxCNC/linuxcnc/commit/b96c...de5e67d2dde0339bece3 )

So, it must be the first one causing the issue.

Did you try adding a queue-buster as suggested? (Not that that is the right fix, but maybe it will tell us something)

I don't have the tab with "7i76 I/O,

 

Why not just close linuxcnc when you want to do manual machining?

I appreciate the time you spent to reply. You provide very good insight that made this work.
What I did was to put 4 in the axis scale and then I put 2500 in the encoder scale. For what I understood from your reply, Linuxcnc takes the 2500 counts and moltiply them by 4 (quadrature) then it divides it by the axis scale (4 again in this case). It was a bit confusing when reading the Mesact manual. I think that manual needs to be revised to explain this better for novice like me.

I tested this by changing a leadscrew with a 5mm pitch one. I had to place 5 in the axis scale and 2000 (2500 x 4 / 5) in the encoder scale. this worked also. I think this is such an important detail that should not be missed when setting up servos. So thank you all.

I was able to achieve a reasonable tuning as well following the servo tuning advice in this forum. I might have to tweak some small Ferror deviation at the very beginning and very end of the move. Lots to learn.

Thanks a lot sir. I was able to make this work. Indeed the axis scale is in my case (direct motor connection to the leadscrew) equal to the screw pitch. For the max velocity I had to back it a bit, to avoid the motor to run away after the full acceleration was completed.

If you are in the EU, eusurplus.com has the 7I97T in stock

If in the US other options would be

7I80HDT + 7I36 + optional 7I84  ( 4 encoders, 4 analog outs, 4 drive enable outputs, 16 inputs, 7i84 adds 32 inputs 16 outputs )
7I36 has encoder fault detection but is only for differential encoders

7I94T + 7I83 + 7I84 +7I89 ( 8 encoders, 6 analog outs, 32 inputs, 16 outputs )

7I94T + 7I83 + 7I84 +7I85S ( 4 encoders, 6 analog outs, 32 inputs, 16 outputs, 4 step/dir channels )

7I95T + 7I83 (6 encoders, 6 analog outputs 24 inputs 6 outputs 6 step/dir channels) 

We should have more 7I97Ts around January/February and the 7I77s replacement
(7I77U) around March

You should get a screen like this:

 

If not. it may be that you have hit a locale bug in pncconf and may have to
temporarily set the locale language to  en_US to work around the issue.

Hallo,
ich bin gerade am Umbau einer ISEL CPM3020 von IMC4 auf MESA 7i76EU. Die Kommunikation von LinuxCNC zur Karte funktioniert.
Aktuell hänge ich an der Konfiguration der Referenz- und Endschalter fest. Ich versuche via Pncconf die Pins festzulegen, finde aber im Menu "Mesa Karte 0" nur Zuordungen für TB2/TB3, P1 und P2. Bei P1/P2 könnte ich die Schalter zwar anlegen, dann bekomme ich aber Pin Nummern die m.E. mit den Field I/Os nichts zu tun haben sondern nur mit den I/O Expansion connectoren. Ich habe trotzdem mal darüber die Schalter konfiguriert, das Ergebnis sieht in der HAL Datei dann wie folgt aus (Leerzeilen entfernt):# externe Signaleingänge
# --- MIN-HOME-X ---
net min-home-x     <=  hm2_7i76e.0.gpio.017.in
# --- MAX-X ---
net max-x     <=  hm2_7i76e.0.gpio.018.in
# --- MIN-HOME-Y ---
net min-home-y     <=  hm2_7i76e.0.gpio.019.in
# --- MAX-Y ---
net max-y     <=  hm2_7i76e.0.gpio.020.in
# --- MIN-Z ---
net min-z     <=  hm2_7i76e.0.gpio.021.in
# --- MAX-HOME-Z ---
net max-home-z     <=  hm2_7i76e.0.gpio.022.in


Eine Konfigurationsseite für TB5 oder TB6 zur Konfiguration der Field I/Os kann ich nicht finden. Wo ist mein Denkfehler? 

Hello everyone,

I'm looking for advice for making an industrial robot retrofit.I have the opportunity to bring an old 1989 Motoman L106 back to life. This robot worked at the former Santana factory, likely welding Suzuki vehicles (Samurai, Vitara, or Jimny). It comes with a YASNAC ERC cabinet that appears to be well-preserved.While I haven't conducted electrical tests yet, the drives (Yaskawa ServoPack CACR-SR units) which were reportedly operational when taken out of service about 15 years ago seems in ok state. 

My current thinking is that the most sensible approach would be to keep the original servo motors and drives, and add a modern control layer to interface with LinuxCNC.I was considering a MESA FPGA board like the 7I97 (or a 5I25/6I25 + 7I77 combo) to handle the analog 0-10V control signals required by the CACR-SR drives.The problem is that these MESA boards seem to be out of stock everywhere. I'm not sure if this is due to obsolescence or high demand. What are the viable and currently available alternatives for a robust LinuxCNC interface to control these analog 0-10V servo drives?Any information, insights, or advice on this project would be greatly appreciated!I'll share photos of the robot and the cabinet/drives below for better context!
 

  Hi,

I have now created another configuration for 1 axis and tested it on each servo. Each servo is responsive and the pdo mapping is now correct. Now I have created the complete configuration and am getting the following error 
HAL: ERROR: duplicate variable 'lcec.0.A6.control-word'
LCEC: exporting pin lcec.0.A6.control-word failed
LCEC: failure in proc_init for slave 0.A6

Where am I going wrong?
 

That worked but ultimately what I'm trying to do is add that line to my custom_postgui.hal file. 
My glade file works good but there is one LED that I can't get working. 

glade.pdt_motion_control.hal_led1
And
pdt_motion_control.hal_led1

As used in the picture in custom_postgui.ha,  neither will boot Linux CNC and both give message pin doesn't exist

Thanks
Kent

Thank you, Andy, and sorry for pestering.

tommylight wrote:

Am i understanding this correctly:
A software solution was implemented in LinuxCNC for a hardware problem/issue ?
It does seem like it, or what am i missing?

Not really. The problem was that LinuxCNC was setting the status to "not probing" before the end of the deceleration stage of a probe move. In cases where the probe triggers more than once (as many will) this led to a "non probe move" error during a probe move. 
Discussion here:
github.com/LinuxCNC/linuxcnc/pull/3534
In response to this bug report:
github.com/LinuxCNC/linuxcnc/issues/2926

 

Can you upload a back of your configuration made from clicking BACKUP CONFIG on the settings tab inside of qtplasmac please?