Advanced Search

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.