Advanced Search

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.