Advanced Search

This is all kind of weird. I tested at the weekend the motors with different microsteps. If the levelshifter are the limits, with less microsteps I should have been able to run the motors faster, or? I am pretty sure that this wasn't the case. The motors stalled around 2100mm/min. I set up the machine that it would to max 1950mm/min. Tonight when I tested it again the motors stalled even at 1950mm/min.

Also I noticed that when I am not moving the axis, a stepsignal was created. The motor did not move but you could hear and see that the Tang was sending step signals. I increased the mircosteps from 10 to 16 in compare to the last time I tried the machine. Has that something to do with the set up of Linuxcnc?

I have to say that the wiring is currently breadboard style. I guess that won't help with 20khz plus signals.

Hmm, I must have made a mistake when measuring the signals. The Tang gives out a perfect 50% duty cycle. I was sure that the level shifter made the same. however they did not. The level shifters make something weird out of it. The level shifter have EL817 coupler on them. The datasheet shows cut off frequency fc =80khz. If I read that right I should not even be around 25% of what they should be able to do. They do have an LED, I wonder if a pulldown resistor would help???

I think @meister said, that I could connected the breakout board directly to the outputs of the Tang. I might try that.

 
 

OK that's probably supported.

When I get a chance I can make firmware for a 7I76E with one Fanuc
channel on the serial expansion port for testing. I seems that that's a 1M
CPR encoder.

Yes, it’s 4 wire - here’s a section of the schematic that labels the wires: 

 

Labels read: SPD, *SPD, SPQR, *SPQR. 

Earlier today I plugged those four wires on the live tool motor into the encoder input on the ultra3000 drive with 4.7k pull-ups to 5v thinking it was an incremental pulse coder… I’m hoping that didn’t cause damage 

Won't last, it's a tool table index issue. It will start again randomly. Be careful since you're using atc as it may or may not cause an issue.

just as an aside, I uninstalled and reinstalled using the deb method with no issues whatsoever. Took about 15 minutes total to download and do everything. At the least I might try a second SSD and have a 2.9.3 version ready to go just in case, cheap insurance if you're using for business. Also, it may be wise to remain on the lockdown version until they release 2.10 as lockdown. Will avoid these hiccups in future.

Hostmot2 has support for the older RS-422 (4 wire = req/data) Fanuc pulsecoders
Can you find the pinout of your encoders?

Hello, 

I am working with an early 90s (installed 1992) Hardinge Conquest Model CS-51. I have installed Allen-bradley Ultra3000 drives for the Fanuc red-cap servos (10s, 10s, 5s, 20s models). Today in testing I realized that the encoders are "PULSE CODER SERIAL C" type. Specifics: PART NUMBER: A290-0561-V571, (A860-0350-T011) on two of the motors, I haven't popped the cap off on the others. 



Currently I have wired in a MESA 7i76e to control this machine, what would be the most cost effective way to read these encoders? I would really like to not have to replace the encoders. 

I also have a MESA 7i97 available if that makes it easier, and the Ultra3000s can take analog input or step/dir so either card would work in this setup - it just depends if either can directly interpret the serial encoder information... My research is falling short, maybe someone can point me in the right direction. 

I'm aware of the Pico systems stuff, but thats another 600USD + (for the 4 servos: x z turret & live tool) to get the job done, while there seems to be some [of the encoders from the serial pulse coder line] that mesa cards and parallel ports can read direct.

Any help would be much appreciated!

Is this an open loop system or is there position feedback to LinuxCNC?

The re-numbering workaround seems ok for now.

No way I'm going to risk 3 weeks of linux/LCNC installation misery only to go through it a seconds time for 2.10, 'cause that what always happens whenever I try to install it.

I'm in Ontario, Canada

Thank you for your generous offer. I was able to get it to boot up with 3 of the ram cards removed. Will see if replacing them will work as well. I am in Florida, USA.
Are you in this country?

Thanks again,

Routerworks

it is the same, the message is just better exposed in qtpyvcp. i posted axis results so it would be easier to test and would remove the use of a different gui from the troubleshooting equation.

if you want the error gone install the lockdown 2.9.3 until they get the issue sorted in 2.10.

did my first cuts on the Fehlmann to make the crane plate to move her to my new shop.










when I was circular milling I found that I had step losses. No errors in the drives, so this couldn't be. Since the drives are closed loop.
After some digging I found my stupid mistake when transferring the max acceleration from the drives to linuxcnc. It never showed till I really used a very slow movement on the Z axis.
So I dropped the acceleration in linuxcnc.
And now I get two strange things. Sometimes the Axis are oscillating shortly like a bad tuned PID system. I can see it on the dro, so it comes from linuxcnc also the machine now sometimes misses the reference switches, I can see that they are triggered. but the machine keeps traveling till hitting the limit switch. when I stop the homing before it behaves normal homing with the reference tripped.

Any Idea where to start searching?

STEPLEN (Stepper intervall in ns) 5000
STEP_SCALE = 1250
MAX_VELOCITY = 150
MAX_ACCELERATION = 150
STEPGEN_MAXVEL = 200
STEPGEN_MAXACCEL = 200

Thanks

Patrick

Is there anything further I can post or attach here (or on GH) to assist?

The error Lcvette posted on GH wasn't exactly the same as mine - at least I don't think so.

I wonder if at that speed you're getting near the max speed of the level shifter? How does the tang look at the same speed as the paraport?