rs485 huanyang speed control

BrendaEM wrote:

The Test2 example has likely needless PWM code in it, in what looks like the spindle section, which makes me trust it less as an example to learn from.
"setp pwmgen.0.pwm-freq 100.0"

There are at least three ways to control a VFD.

1) Software PWM: Typically using the parallel port. Hal needs to load a pwmgen component. Variable duty-cycle digital output is converted to an analogue voltage to become the speed reference for the VFD. The simplest converter is a resistor/capacitor filter, but that can only go up to PWM voltage and will thend to be non-linea. An optocoupler circuit can address both these issues:
photos.app.goo.gl/eTzgyahpoCThL9EdA
Or you can save some trouble and use: store.mesanet.com/index.php?route=produc...id=205&search=spinx1

1a) Software PWM on an FPGA card or similar. The PWM runs on a Pico or Mesa or similar card. There is no need to load a pwmgen, as there is one "in" the card with pins created by the driver. Normally you would use a daughter-card which already contains the PWM to analogue circuits. Typically these can output bipolar voltages (-10 to +10) if required.

2) Hardware analogue output. This is what the 7i76 and 7i76E do. A serially-accessed hardware drives a digital potentiometer.

3) Modbus (or other serial connection). Numbers are sent to the VFD. It decides what to do with them.

I have attached my spindle.hal as an illustration of why HAL samples tend to be of limited value; It uses a custom component to select gears from an electrically operated gearbox, it uses resolvers and it contains a PID component for closed-loop speed control that isn't actually used. So only about 8 lines would be any use to another machine.

You don't need classic ladder to run the hy_vfd. That is a completely different way to run a modbus device than the hv_vfd HAL component.

BrendaEM wrote:

....to some of the lines in the spindle block I have:

loadusr -Wn vfd hy_vfd -n vfd -d /dev/ttyUSB0 -p none -r 9600
net spindle-cmd-rpm     	             <= motion.spindle-speed-out
net spindle-cmd-rpm-abs		             <= motion.spindle-speed-out-abs
net spindle-cmd-rps                    <= motion.spindle-speed-out-rps
net spindle-cmd-rps-abs                <= motion.spindle-speed-out-rps-abs
net spindle-cmd-rpm-abs		             => vfd.speed-command
net spindle-cw motion.spindle-forward  => vfd.spindle-forward
net spindle-ccw motion.spindle-reverse => vfd.spindle-reverse
net on motion.spindle-on	             => vfd.spindle-on
net spindle-at-speed                   => motion.spindle-at-speed

I am _so_ tempted to just give a bunch of documentation links to prove that it is all there...

The vfd name is different because you have made it different in the loadusr line.
linuxcnc.org/docs/2.4/html/hal_basic_hal.html#r1_1_3

You are loading a component and waiting for "vfd" to be ready before continuing, then passing some parameters to the hy_vfd function, namely a name change (-n) a port name (-d) and a baud rate (-r) and a parity (-p)
So you could just useor even set the VFD params to the hy_vfd defaults (38400 baud, odd parity) and useIn either case the hy_vfd pins would all be called "hy_vfd.pin-name"

In your HAL the linesShould mean that the command signal is going to the VFD. You can check this with the halmeter (in the Machine menu with Axis and Gmoccapy, "loadusr halmeter" in a terminal in some other GUIs like Touchy)
If the speed command is changing then my suspicion is that PD002 isn't set to 2-communications port