Advanced Search

Halls are fine for fan motors and the like, Good servo drives typically use a higher
resolution commutation angle source to avoid torque ripple. Of course if you have Halls and
an incremental encoder, you can use the Halls for initial movement and then calibrate
the incremental count on the first Hall edge.
 

  I already have MESA MODBUS working, with one I control a VDF and with another an I/O card with 4 inputs and 4 outputs. The only problem is that from time to time this error appears, and fault error 11, both when I control the VFD and the I/O card. I have tried to change the modname.update-hz parameter to 0.1 but when doing so it appears that neither the VFD nor the I/O card receive the commands. According to the documentation for this component, this parameter can help when la, fault 11 appears,

PCW wrote:

I think the point for them is that the commutation angle
is correct at power on.

They could forward the (1 turn) absolute position but that
would require a fieldbus interface of some kind  or some
absolute encoder format output (some drives do this with SSI)

As a curiosity, some older Fanuc absolute encoders used a normal
quadrature interface and sent the absolute position as quadrature 
counts when reset.
 

Can't commutation just be derived from hall sensors? It is an RS485 encoder "SN75176 or equivalent" 5v, gnd, S+ and S-. They're protocol isn't published in the manual, it says "contact" for that info but they didn't bother to give it to me.

The converter module which I still speculate uses the same ASIC says "Brushless AC motor types should be used and commutation can be generated from incremental, or hall sensor signals." which sounds exactly like what I was saying about the standard motor encoder, which the motor probably has a 3 hall arrangement like a brushless DC motor.

The multi-turn encoder does explain the protocol layout with some function code, CRC, 16bits of position, and 16bits of turn. I suspect the 2bytes of turn is omitted by the encoder or ignored by the drive if either is single turn. AFAIC it doesn't matter whether it's ASIC or magic that makes it an absolute encoder, If you turn it on and it can't tell you the shaft angle it doesn't seem like an absolute encoder to me. An M16 with a 2 position selector wouldn't do anything an AR15 wouldn't do.

FreeCAD path isn't tough but you kind of have to know how to use FreeCAD. That's all I've ever used so I can't say if it's good or not, I can just say I can't think of anything I can't make it do on a 3 axis mill.

Don't know of any nesting in the path workbench of FreeCAD. What I always do is join models into a compound and use that model for the CAM which is like a big multiobject model. It has no problem with multi-object models in CAM/Path so I haven't tried to figure anything else out since that works

Only part thats dissapointing is 4th axis. There's some kind of experimental 4th axis features but they did not work well at all when I used it.

I think the point for them is that the commutation angle
is correct at power on.

They could forward the (1 turn) absolute position but that
would require a fieldbus interface of some kind  or some
absolute encoder format output (some drives do this with SSI)

As a curiosity, some older Fanuc absolute encoders used a normal
quadrature interface and sent the absolute position as quadrature 
counts when reset.

If you can prevent PathPilot from re-writing the firmware
you could use firmware with the correct pinout for your BOB

Note that the GPIO pins would not change with different
firmware, but things like the step/dir, encoder or PWM pins
can be moved anywhere.

i think the only difference is the math on the scale gain, as far as i can tell, so instead of 10/rpm , it would be 100/rpm

"So I took axample from LinuxCNC documents, then pins assignment as per your configuration was type mismatch. Assigned pwm pin as regular output pin."

not sure what you mean by this

here are some rough examples of my spindle setups using pwm

github.com/cakeslob/RRW_LAB/blob/main/Li.../remora-xyz.hal#L122

github.com/cakeslob/RRW_LAB/blob/main/RR...0355/config.txt#L100

I just got a response from the guy at DMM, he just says no, the ENCV module can't do anything with a battery.

He also says that the motors have "traditional" absolute encoders. I can verify from working with quite a few of these drives and motors that there is exactly zero visibillity of absolute shaft angle from the drive power on, I just went through the DMM software as well. The only thing you will ever see from that drive after power on is a 0

What am I missing? How is that the behavior of a drive connected to a motor with an absolute encoder? What's the point?

How do I change the input and output pins in PathPilot? 
- I'm using the PCNC 440 setup with 7i92 Mesa card.
- I bought a driver board that doesn't match the 440's pin-out.

Not my first PathPilot build, I've installed it on 2 machines using standard BOB's. They run quite well. 

Some pretty good ideas here:


would probably work better using light dome switches rather than tactile switches, not really sure how the software interface on a StreamDeck works so it's hard to say what's actually necessary but I think the electronics could be quite a bit simpler

Yeah, forgot to ask, if you put your hand on the motor, does it vibrate and how much?

tommylight wrote:

Any LCD with a Resistive touchscreen (new Capacitve won't work), most new PC's have more than one Video output, so that would connect to the free output, the a bit of software to make sure each section of the screen remains the same size no matter what is shown and change the video accordingly, that is all there is to it.
Hardware part is easy enough, software takes a bit more doing to get it right, although i would go for hardware solution to keep the sizes and limits in check, makes it less flexible but easier to use.
Software solution would allow for full screen video and gif's and blinking signs and such, although those could also be done in hardware but would require flashing to change.
-
On the topic of HMI, what would fall into that category?
 

Capacitive's would work, probably better, they just need special consideration. I don't think touchscreens would work that well in general to be honest, they aren't meant to be activated with large surfaces like wide buttons and the touch layer is fragile.

Hard to tell from the plot (higher vertical gain would help)
but it sort of looks like +- 1 count dither. If this is the case
(and that jitter is only +-1 micron or so) you could add some
deadband to the PID controller to lessen the dither.

fiveseven wrote:

the picture is of when i was still building it up its all conected now.

What picture?
Have a read through this, skip the wiring and testing part:
forum.linuxcnc.org/10-advanced-configura...ning-detailed-how-to

rdtsc wrote:

The manual for this drive says: under no circumstances ever switch the power to the drive while the motor is energized, or destruction will result.  

That statement lack the main part: DC side, so should be: never cut the DC side of power to the drives, or to put it bluntly never disconnect/unplug the red+ and black- wire to the drive.
You can cut power to the AC side of things as much as you like.
-
See attache picture, set the KL drives to 1/16 or 1/32 microsteps, test again, should be much smoother running. You can set to 1/64 and would be even smoother, but depending of how you are creating pulses you may need to go lower.
Also, do not push the max out of them, 2A should be enough depending on your motors