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.

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


 

  This is the very end of the message

 Hi, I updated from Linux CNC 2.8.2 to 2.9 and get the following errors when I try and open Linux CNC      

Can anyone help Please
Thanks

The IP address is a 32 bit number internally, so you should be able to pass it as an unsigned long parameter. you would need to convert 192.168.1.1 to 4 bytes in hex, then use setp

I could need a little help. I compiled my kinematics with halcompile --install. And i used the vismach xyzbc-trt-kins (switchkins) demo. I tried to replace the original Kinematics with my custom kinematics and after some commenting out i got this error message. Would be glad for some input to guide me in the right direction.

I continued a little bit and now its this:

Note: Using POSIX realtime
motmod: dlopen: /usr/lib/linuxcnc/modules/motmod.so: undefined symbol: kinematicsSwitch
././xyzbc-trt_cmds.hal:38: waitpid failed /usr/bin/rtapi_app motmod
././xyzbc-trt_cmds.hal:38: /usr/bin/rtapi_app exited without becoming ready
././xyzbc-trt_cmds.hal:38: insmod for motmod failed, returned -1
20961
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime