Advanced Search

PCW wrote:

That is a PCI card (a 5I20)

If the motherboard is OK, probably the easiest path
is to just get a new harddrive

Is there any chance the original HAL and INI files  are available or
can be salvaged from the 

Storage appears to be a compact flash card. 

Hi everyone- no, havent yet given up
But after having shot 3 Mesas, I got them repaired luckily- this took a bit longer but now I seem to be back in the race ...
At the moment I could really use some help please. I am trying to get my motors tuned but this seems to be tricky.
the motors are Fanuc A06B_522_B042_7000  with a  AB06_650_B200 drive (the Mesas  a 7i80HD-25 and a 7i33 connected if this is of importance)
Has anyone some experience withe these Fanuc components and probably got them tuned sucessfully?
I played around quite a bit but do not get it under control.
I just can get the motor either going forth and back about 1/4 turn or if it stands still it is vibrating pretty much.
I have no experience in motor-tuning. the smaller the P value gets the smaller the forth and back movement is.
Changing the I value does not do anything, but a small D value of 0.3 almost keeps it in the position but then the vibrations come.
Any suggestions appreciated
Thanks

Sigi

Yes I was , yes it counts if I lower it. I bench tested a 360ppr and I noticed when I moved it with fast acceleration with my hand it would stop. I then hooked it up to the machine with a 600ppr. It starts counting again if I lower it. When I bench tested it and the PV stopped counting , the pulses where still ok on the oscilloscope. I'll try and see can I see the pulses in halscope.
These are Chinese encoders , supposed to be rated for 100khz

That would be a safe option for the time being as 2.9 is unaffected by this issue.

I have opened an issue  on GitHub.
 

PCW wrote:

You may get a bit more speed by increasing the inm's scan rate from its default
20 KHz to say 100 KHz (this decreases the default digital filter fast time constant (5 clocks)
from 250 usec to 50 usec)

1. If you use the 7I96S firmware with MPGs on P1 it would just be the second inm (inm 1)

2. No, you need to use differential receivers (say 26LS32)  for that

3. its a bit tricky because LinuxCNC has many offsets in its DRO readouts
at the minimum you would need to set this offset. 
(perhaps by using the scale components  offset pin or manually resetting
the counters at 0)
 

1) okay, seems logical to start with the inm scan rate, because I have to make a bit of an effort to miss pulses now, so if I'm really lucky perhaps at 5x, it might be fast enough?
How do I tweak the inm scan rate?

2)  26LS32 looks good, I used similar DS3486's for something similar a fair ways back.

3) In axis there are two tabs; Preview and DRO it's not clear to me how these differ? I'm assuming that when I start driving the steppers/servos the values (for Z and X)  on those tabs will be updated by Linux based on the steps sent to the drives and whatever scaling is specified. I'm not sure if I can override those values with the actual values that I get from the scales, and if not,  can I somehow get the actual values displayed somewhere in the GUI?

Much appreciated

See also this one: github.com/LinuxCNC/linuxcnc/issues/3238

You may get a bit more speed by increasing the inm's scan rate from its default
20 KHz to say 100 KHz (this decreases the default digital filter fast time constant (5 clocks)
from 250 usec to 50 usec)

1. If you use the 7I96S firmware with MPGs on P1 it would just be the second inm (inm 1)

2. No, you need to use differential receivers (say 26LS32)  for that

3. its a bit tricky because LinuxCNC has many offsets in its DRO readouts
at the minimum you would need to set this offset. 
(perhaps by using the scale components  offset pin or manually resetting
the counters at 0)

Many CNC controls do not require a new line (or block) of g-code to repeat a G0, G1, G2, or G3 code on a new line if they are not changing from the previous lines, because those codes are considered "modal" (ie they are remembered). This allowed controls to save precious memory space, from the days of paper tape and when 1024k was considered a significant amount of memory. Linuxcnc is no different and will work fine with the extra repeated g-codes omitted.

Your problem with arc radii not matching the begining and end is an unrelated problem, and results from your cam program taking liberties with rounding errors. Usually there are settings in the cam program to adjust how closely the cam program must calculate the arc radius. What those settings are called and were to find them are not always straight forward or easy to figure out. (I'm not familiar with your cam program to make suggestions there.)

There are settings in Linuxcnc that will allow you to change the limits where an alarm will be set for these radius calculations. See this part of the Linuxcnc documentation.
linuxcnc.org/docs/2.9/html/config/ini-co...sub:ini:sec:rs274ngc

Works very well, no problems.
Thanks

Ok, zelo, do a quick test to see if the speed doubles if you reduce the scale by half


Murphy, were you one of the guys modding the board for better encoder signals?
500rpm @ 2400cpr isnt very fast, does it continue counting if you lower speed?
You will probably need to halscope it. I dont know how many people are using encoders with the rt1052

Your PID and deadband settings. I suggest bringing the topic into the Remora ethernet thread

edit, oh man this was an old thread

Wow, off the rails is definately where that went.....fascist? Where on earth did that come from? We're talking about serial protocols....I don't think I tried to suppress your freedom from my keyboard.

Point was you theres some kind of misunderstanding about how asyncronous serial works, even though that post was edited out of existance now. I have no idea what this last post has to do with anything. All I said was in service to Baudrate != Bitrate. Though it's generally OK to colloquially just say it like it does.

Moved to EtherCAT section.

2.7.n is probably Debian Wheezy, so it can not be upgraded to 2.9.3 due to changes in Python, mostly.
For Wheezy, you need to use
sudo apt-get update
sudo apt-get upgrade
It might just upgrade to 2.8.n as that was the last Python 2 version of LinuxCNC, although Wheezy has reached it's "end of life" a long time ago so no more updates for it.
-
You can install the new 2.9.3 from the downloads page, and if it tells you it can not find files/usb device, just unplug the USB, wait 5 seconds, plug in the USB, wait 10 seconds, click on continue/next.
Be aware that if using an old PC, it is much better to use the Ubintu version i linked above or the existing Wheezy version as they use RTAI kernel, while the new ones use RT-Preempt kernels and thy will have worse latency on old systems.

Hi Rod,

Thank you for the leg up on the development environment. I've spent a chunk of time with it.

Should I use this forum thread to have conversations or would somewhere else be better?

Tom