Advanced Search

well that comment is from the creator of the spindle section (tall83). It is not from my servo so it should be unrelated to my setup.
Unfortunately my manual does not give any info for the step scale.

I think the output scale should be 166.6666 (or -166.6666) as the ini file comment suggests.
This is completely unrelated to the encoder scale (which seems to have been factored in)
(at least assuming 10000 steps per turn)

with both you mean the step scale and encoder scale i suppose.

Yes i agree, the problem is i dont really have a way to find that out myself i believe.
The parameter that shows the factory default says 1024 motor resolution per revolution.

you should give it a shot if you are able, unrelated to probe

but the on abort stuff doesnt look like it will effect probe stuff, as it is advised to use the probe abort button on the probe panel [x] button

That indicates the original issue, the scaling in incorrect (on one or both)

i did invert it to:
OUTPUT_SCALE = -68.26667

and now the spindle turns correct.

The Problem with the difference between spindle-fb-rps and spindle-speed-rps still persists tho. spindle-fb-rps is negative and spindle-speed-rps is positive (in case of m3).
This lead to spindle-at-speed never beeing true.

Edit: even when i invert the encoder scale the difference btw. the fb rps and speed rps(commanded) is too big for spindle at speed to be true.

Its this (in the ini file)

OUTPUT_SCALE = 68.26667

Edit the ini file, not the hal file.

i get what you mean but i dont have a step scale/ direction output in my hal.

You need to reverse the sign of the step scale (or invert the direction output)
to reverse the spindle

 

Hello, I am trying to read the spindle load using Modbus. It works fine with the Windows program, but with Linux and mb2hal, it does not. The problem occurs when I attempt to read address 420—it does not return any value, only increments the error counter. Some addresses can be read, but others cannot. What am I doing wrong?Here is the configuration, along with a screenshot of the working Windows setup.  

 

 

 


ps now working!  i just changed this parameter MAX_UPDATE_RATE

This is going to sound so stupid, but might as well own up to it.
I found out the problem was not the switch but the motor connection. I have a nuc and the mesa board in a mobile station I can roll around the shop while the CNC router, drivers, power supply, etc are stationary. The reason I designed it this way was to use the mobile station for testing stuff I intend to convert into CNC (lathe, mill, etc). It looks like my solder job for one of the motor signal connectors was somewhat faulty and allowed it to only be driven in 1 direction. Probably a cold joint, which also explains why it was happening only occasionally.
My guess is that the cnc attempted to hold the motor still after the limit was hit (hence the delay) but only received one direction signal and not the other, there by pushing the motor into the switch.

So it says 142v on the servo but then it says 200v inverter on the same tag. The machine they were removed from was on a 400v 3 phase supply, my 230v being one of those phases to neutral. I do have a transformer capable of the current requirement.

i edit the line:
setp hm2_7i95.0.encoder.05.scale - [SPINDLE_0]ENCODER_SCALE

with a minus but that alone does not change the direction of m3/m4.
If i now go ahead and change a direction parameter on my servo drive to reverse
the spindle turns cw via m3 and ccw via m4 while spindle-fb-rps and spindle-speed-rps signal are both positive at least tho still slightly different values.

So i guess i can hack my way around the m3/m4 problem but still the problem with the speed is not solved by this.

at a certain speed close to 1000 rpm and above the spindle-at-speed never becomes true.

Hi Bkt,

You can install it "rip" only, but you can not run the new trajectory planner. It's still being coded.

custom kins is the same as 2.10?
I don't know wich kins versions are in. Its a recent linuxcnc git clone.