Advanced Search

What type of control do the drives/VFD take?
What encoders/resolvers are on the motors?
If they do turn out to be analog +-10V ones, a Mesa 7i97T should do just fine, and if you do need more I/O you can add a 7i84 with 32 inputs and 16 outputs.
Here are some topic to give you an idea of what is involved:
forum.linuxcnc.org/30-cnc-machines/31792...-sbz-130-01-retrofit
forum.linuxcnc.org/30-cnc-machines/33529-hurco-bmc-20p-retrofit
forum.linuxcnc.org/show-your-stuff/34986...nd-proma-thc?start=0
And detailed info on wiring and tuning
forum.linuxcnc.org/10-advanced-configura...to-example-mesa-7i77

Those motors do not seem to have encoders at all, so will not do for CNC control as you found out and i am late to point out.
You can try adding encoders as the lid is easy to open, but i fear it might be way to much work to attach them due to short shaft and limited space.
Might be possible using those magnetic encoders as they are simply glued to the shaft, so only drilling a hole for it and for the electronic on the lid, but i never used them so i have no idea how good and reliable they are.

You should use the M100 to call python programs to do this, see the following example.......linuxcnc.org/docs/stable/html/gcode/m-code.html#mcode:m100-m199.

Hi,
I have a machine that has a Hypertherm 105 Sync source on and I am having issues getting the THC to work correctly.
I had to adjust the THC_delay to 5 seconds before I could get a stable voltage reading for Autovolts. The torch will go down to the cut height but starts moving upwards before the THC_delay has timed out. The cut voltage seems to settle at 55V but the torch moves up until it reaches 75V and stays there.
The strange thing is it will cut the first cut correct and then misbehaves after that.
Any ideas where to fiddle?

As the debug message indicates, line 6 in your 'Slabber.hal' expects a value for the keyword 'AXES' in the [TRAJ] section of your ini file.

Not sure, halcompile output looks ok. Starting your config from a terminal may give more debug information.

Thank you, everyone, for your responses. Really appreciate it!
We had already connected the negative direction and step pins of the TB6600 driver to ground using a pull-down resistor. After taking PCW's advice and supplying 5V to our breakout board via the USB cable, all our problems with erroneous movements and strange noises disappeared.

Points to note, though:

We had already made the ground common across the whole system.

Optocouplers are pre-installed on this breakout board.

jimmyrig wrote:

Easiest way would be to make another config.
leave the old one for when you need position.

In the new config change the A to be a spindle.

Lookup step and direction spindle for examples. If you dont want to mess with it I could do it for you.

Then it should work as you intend with me s1000 $1
 

Yes, I would plan to have an alternative config for this use case.

I've already searched around and tried tweaking things, but wasn't getting any success. I think I may be getting stuck up on the motion related HAL entries but I'm not sure. I would be very grateful if you could sort it out for me.

Does this help at all?
wiki.linuxcnc.org/uploads/orient.svg
It's one potential way to do it.

Andy, I wouldn't know where to start with this.

Upon further investigation I think these motors do not have the ability to speed control at the precision required. They are more for like a conveyor system pre set the speed and let er rip or control it with a potentiometer. I think they could still be very useful for projects around the shop maybe to power a few bridge Cranes that don't roll as nicely as they should anymore. 

I think it might be a comms issue relating to the filtering issue around the internal voltage regs. All the ref designs I've seen use 4.7uf cap with the 2 100nf with the inductor. I'll have to wait for some caps to come in.

Using openFGPALoader with the flash over SPI works fine (load a config directly to the FPGA then communicates with the FPGA ), so I can reliably write to the flash.

Looking at a session with wireshark, the board stops comms first. And the time it takes to happen can be kind of random. I'm prepared to accept that the design may not just work due to "Reasons" (bad layout, signal trace lengths, lack of knowledge of my behalf). I may have to read the mesaflash code and work out the programming protocol to get a better understanding.

Hi Friends, 

I am pulling my hair out trying to determine how many steps it take for my angular C axis to make one full revolution. I recently had to redesign the tangential cutting head so while I had it off the machine I wanted to tune it as much as possible with the tools i had available  (scale, min max jog speed, etc) 

So i set out to determine how many steps it would take the motor to rotate the output shaft one full revolution. After a few days of doing what I thought was simple calculations to little to no success I tried to go bottom up. That is, hard coding the number of steps and adjusting based on behavior. this took like 5 minutes to get it pretty close.. However, its not perfect and I'd like it to be close i don't understand why it is the number it is. I don't think i understand the 'Pulse/rev' table on the driver. 

The bottom up number i got for steps per revolution was around 540. 

Current settings:
Pulse/rev (dip switches) 1600
Motor Step Angle 1.8
Pulley Ratio :3.12

No matter how i combine those numbers i cannot seem to get anywhere close to the 540, the number that actually produces somewhat close to a full revolution. 

Any help or explanation is greatly appreciated. My end goal is a precise calculated steps per revolution. 

Ps. i am ignoring that this is a servo motor and capable of closed loop control, not sure if this logic holds but i would like it the be as close to correct as possible then use the PID controls to correct error and not lean on it due to sloppy setup work. 

If its just a flash issue, ( normal Ethernet comms  are reliable )
It may possibly be a a compatibility issue or perhaps signal
integrity or some other flash EEPROM connection issue.

In all honesty if the kernel gives no issues I wouldn't bother upgrading, from memory there isn't much of a difference in performance.

The first issue I run into is that my gear track is 5 TPI The shaft diameter to the motor is 18mm does anyone build gears with metric bores and imperial gear pitch? buy a 5/8 bore pinion chuck it up in the lathe and bore it out to 18mm? hand file to broach out the keyway? a 20 T pinion should get me to about 600 ipm if my calculations are correct. which is honestly to fast but I am worried a 10t will not have enough contact and skip or slop.

I have a spindle that has motor pulley belt pulley
after has a geartrain with 2 positions-speeds.
I want to mount encoder to second pulley shaft before geartrain.
Iam confused how to set ini file values
max_speed min_speed encoder_scale output_scale etc