Encoders

but my step scales are set between 4046 and 4071

but you are assuming that the area of the ballscrew you are measuring is accurate to the pitch of the ballscrew, but my concerns are if the ballscrew is a 5.08rev/in and the first commanded IN of movement actually = 1.002" and you use that scale for the entire ballscrew wont that compound across the entire length of the screw and negatively affect you at the tail end of the screw? so at commanded 16" you would actually be somewhere closer to 16.03". I would think you would want the nominal value of the ballscrew since thats what they are basing the +/- value off of on the C7 accuracy. so the first inch might be 1.002 but inch 2 might be .998, but as you average the discrepancies over the length of the screw you get 1". and again if you use any specific range of the screw to base your calcs on youll compound those discrepancies as you move.

not sure if that makes sense, but that was the logic I was using when I did my calcs. maybe im splitting hairs here, and if I am way off please correct me, I just wanna build the best thing I can under the constraints I have.

Not sure what type of mill you're working with but it's all about how you wanna spend your money. If I wanted to spend what I figure you spent on the Clearpaths (the one Clearpath I have was ~$1000 all in), I would have bought DMM (or similar) axis servos and really good ballscrews.

I ended up paying $1400 for 3 servos, the DC power supply, the power supply breakout board, cables etc. I didnt think it was too bad, i dont think I could have gotten decent ballscrews alone for that let alone an entire motor/motor controller system and ballscrews. but I didnt know about DMM till after I bought these.

here is the build thus far.

photos.app.goo.gl/T8qGS1b2s8TRNwRR8

natholego11 wrote:

but my step scales are set between 4046 and 4071

but you are assuming that the area of the ballscrew you are measuring is accurate to the pitch of the ballscrew, but my concerns are if the ballscrew is a 5.08rev/in and the first commanded IN of movement actually = 1.002" and you use that scale for the entire ballscrew wont that compound across the entire length of the screw and negatively affect you at the tail end of the screw? so at commanded 16" you would actually be somewhere closer to 16.03". I would think you would want the nominal value of the ballscrew since thats what they are basing the +/- value off of on the C7 accuracy. so the first inch might be 1.002 but inch 2 might be .998, but as you average the discrepancies over the length of the screw you get 1". and again if you use any specific range of the screw to base your calcs on youll compound those discrepancies as you move.

not sure if that makes sense, but that was the logic I was using when I did my calcs. maybe im splitting hairs here, and if I am way off please correct me, I just wanna build the best thing I can under the constraints I have.

Not sure what type of mill you're working with but it's all about how you wanna spend your money. If I wanted to spend what I figure you spent on the Clearpaths (the one Clearpath I have was ~$1000 all in), I would have bought DMM (or similar) axis servos and really good ballscrews.

I ended up paying $1400 for 3 servos, the DC power supply, the power supply breakout board, cables etc. I didnt think it was too bad, i dont think I could have gotten decent ballscrews alone for that let alone an entire motor/motor controller system and ballscrews. but I didnt know about DMM till after I bought these.

here is the build thus far.

photos.app.goo.gl/T8qGS1b2s8TRNwRR8

Actually I wasn't assuming anything. By putting in your exact pitch calculation you are assuming that the pitch is accurate. I'm entering a calculation based on measurements because I know it is not. I don't care to fuss around with mapping ballscrews as my average is good enough for the tolerance of the machine I built. If you do wan't to map the ballscrews, wouldn't you want to measure your average real step ratio calculation with a physical device rather than assume it were closest to 4064 before you started?

I honestly don't trust ballscrew maps, but they could be fine, I don't know. If I wanted to get a really really precise machine I would just buy and make sure I had really good screws and measure and twak until my static step-scale were close as possible. Electronics have extremely high resolution but the effort to overcome mechanical inaccuracy is far greater than well......being mechanically accurate.

If you really want really good accuracy with cheapish ballscrews than you did right by using linear scales because you are constantly ruling out mechanical inaccuracies with high resolution direct measurements. The problem is that to do so your effort will be much greater than knowing your screws are accurate as you need them to be, and only measuring how much you've spun them (motor encoder).

Your motors cost you $1400, but your scales cost ???. If you went the route of really good screws then why use scales?

the scales were $150 total, again, Chinese, but from what I have seen on my lathe DRO they are pretty good for the price.

back to an earlier conversation

wiring......
You need to put >14v-24v+ on pin 4 or 16 of the DMM DB25 connector
Then put the DC common of that same power supply on the OUT0+ pin (for example) of the 7i96
connect the OUT0- pin to pin 15 of the DMM DB25(enable)

Then in hal I do it like this....
(Powers the drive external contactor)
net estop-out <= iocontrol.0.user-enable-out
net estop-out => hm2_7i96.0.ssr.00.out-01

(enables the DMM drive with the power button)
net machine-is-on <= halui.machine.is-on
net machine-is-on => hm2_7i96.0.ssr.00.out-00

(enables the spindle stepgen)
net machine-is-enabled <= motion.motion-enabled
net machine-is-enabled => hm2_7i96.0.stepgen.04.enable

I tried this, and have it wired as you recommended it, LinuxCNC starts up and seems to run ok, but the spindle isnt running and when I check the SSR on the 7i96 im not getting anything(24v) across the leads. so I dont think its closing, is there something I am missing?

can you explain a little further the statements above? im not sure I understand whats going on here. I read the introduction on the HAL so I have a rough idea of whats going on. but again the SSR is not closing so the voltage is not activating the DYN4 (which is now set to active low).

The DMM drives use sinking inputs/outputs, so you're in good shape with the 7i96 to outputs if you want to enable the drive with them as they are independent. The inputs are all based on the input common, so if you want to use sinking inputs for the DMM drive, the rest of your inputs are gonna have to be sinking too. I run a 7i76e on my mill and had to jump through hoops with optocouplers to get the drive I/O going.

when you say "the rest of my inputs will be sinking too" are you talking about all inputs into the 7i96? or only the ones related to the Dyn4?

natholego11 wrote:

I tried this, and have it wired as you recommended it, LinuxCNC starts up and seems to run ok, but the spindle isnt running and when I check the SSR on the 7i96 im not getting anything(24v) across the leads. so I dont think its closing, is there something I am missing?

can you explain a little further the statements above? im not sure I understand whats going on here. I read the introduction on the HAL so I have a rough idea of whats going on. but again the SSR is not closing so the voltage is not activating the DYN4 (which is now set to active low).

Is the SSR output light coming on when your hal signal toggles enabled? If your checking against DC+ of your power supply, and you have connected DC- to the common of the SSR# channel, then the other side of that SSR channel should show the voltage when the SSR is active. You likely won't see a good continuity check between SSR+ and SSR- because it is not a mechanical contact, it's a transistor of some type. You can try changing whether you supply DC- to SSR- or SSR+ and connect the opposite side to the DMM enable as the output. SSR+ and SSR- imply that current flows from negative to positive so DC- should connect to SSR- then the output is SSR+ but that doesn't mean that is actually the case, There may be some protection diode in there that only allows current to flow in 1 direction, it's not really explained in the manual. Maybe PCW will chime in, but I'd think he would have corrected me when I explained it to you the first time if I was wrong. Just know that one side of the SSR is the "common" and the other is the output, but you get nothing unless your SSR common is referenced to the same power source.

I'm not sure I can explain it any better unless you tell me what you don't understand. If your 7i96 isn't showing an SSR output LED then you don't have a hal signal telling it to turn on. You'll have to verify the board is actually turning the SSR on. If not then verify the Hal signal is changing in halshow. You can't chase electrical issues if you don't have a hal signal.

when you say "the rest of my inputs will be sinking too" are you talking about all inputs into the 7i96? or only the ones related to the Dyn4?

You have to understand "common" means 2 different things with the inputs and the outputs.

Your outputs have a per channel common, that is you connect either DC- or DC+ to one side of that SSR channel and the other side of the SSR the same thing comes out of it. Your inputs do not act like this. You have a single input common terminal that drives ALL the inputs in that direction and the actual input needs to be opposing polarity to make that pin change state. The outputs I explained above. The inputs work like if you connect DC+ to "input common" then every input will require DC- to make it change state. So if your machine uses NPN switches, then they will drive your inputs low, so you use DC+ as input common. If you have PNP switches then they drive the input high and you use DC- for input common. If you use mechanical switches, pick one polarity for input common, then send the other through the switch contact and into the input terminal.

The DMM drives only output as NPN, so in order to use them, Use DC+ as input common, but that's what your using, you cannot use a active high input anymore (PNP), all of your inputs are active low. If you use DC- as input common your inputs are active high and hal pins work as expected, If you use DC+ as your input common than the inputs will behave inverted unless you use the hm2_[HOSTMOT2](BOARD).0.gpio.XXX.in-not pin.

And again, you HAVE to connect DC+ to the DMM +14 or +24v pins and the DMM will need that same supply's DC- to reference the inputs or the outputs or none of it works.

ok, Thanks for all the input.

I got all that working, spindle-at-speed etc (my encoder was outputting a negative value, so I had to figure out how to make abs.N.in/out work to fix that, it didnt work to reverse any of the inputs or the hal pin/signal)

so the next step is to get the linear encoders to work, I spoke with PCW and I think I know what needs to happen, but ill update my HAL with that, and check back in, but once I map the HAL pins will the PID functions "automatically" apply and all that will be required is adjusting the PID values? or do I need to do something else to "activate" the PID functionality?

natholego11 wrote:

ok, Thanks for all the input.

I got all that working, spindle-at-speed etc (my encoder was outputting a negative value, so I had to figure out how to make abs.N.in/out work to fix that, it didnt work to reverse any of the inputs or the hal pin/signal)

so the next step is to get the linear encoders to work, I spoke with PCW and I think I know what needs to happen, but ill update my HAL with that, and check back in, but once I map the HAL pins will the PID functions "automatically" apply and all that will be required is adjusting the PID values? or do I need to do something else to "activate" the PID functionality?

The encoder outputting a negative value when running forward is fixed by inverting the encoder scale......i.e. 4064 becomes -4064. The input for your "near" component should be motion.spindle−speed−out−abs because the absolute value scrubs off the sign of the number. Otherwise the spindle running in reverse would never trigger the near component because the speed reads negative (by design) in reverse.

Not sure what you mean by PID working automatically. If it's connected in hal, it's working now. If it's not connected, then it's not. According to the hal file you posted it is connected for XYZ and the spindle, tho the spindle PID is going to bite you. The difference is that pncconf sets up stepgens with feedback from the hm2 feedback pins. This basically means that the PID is a send/receive loop and only checking that the Mesa card feedback matches the request.

You need to replace the feedback from the hm2 stepgen position-fb with the encoder position read back from your scales. You tune the PID with LinuxCNC running and bring up emcconfig, it's called "machine configuration" or something in the Axis GUI when you get there.

so seeing that the DYN4 will do all the PID internally, I suppose i need to remove the connection to the PID on the spindle. is that as simple as setting all the PID values to 0? or do I need to remove the hal components of the PID for the spindle?