Shizuoka AN-S Retrofit Page 2
2017-02-09 MB2HAL and The User Interface
I have started to play with what sort of physical user interface I should have such that I can always reach to a certain spot on the machine to accomplish a task quickly. It isn't really about saving time, but saving parts when I make a mistake or being able to easily set up the machine. I have proven to myself that using an arduino as a control panel input device is fine. I threw it on using mb2hal and althought it isn't quite as fast as I would like, it works. It updates at about 20Hz. I have connected a mechanical encoder, which cost about $1.25 and put the encoder position into one of the integers that are sent over mb2hal to linuxcnc. Spinning the encoder creates more or less smooth motion of the test axis. It only took three lines of hal code to connect it up once I had the mb2hal example up and running on the arduino.
halcmd setp axis.0.jog-scale 0.0025
halcmd net jogwheel mb2hal.RegIn.01.int axis.0.jog-counts
halcmd setp axis.0.jog-enable 1
I learned it IS REALLY IMPORTANT not to enable the jog before creating the net for the jogwheel. When I did it in the wrong order, the rather large number in the encoder counts sent the table sailing away. As a result, I was encouraged to make an e-stop to hang on the front side of the machine. When I moved the "open-face" control panel so it would be safe from harm from the moving table, the e-stop I mounted on it became inaccessible. I really wish I had made that remote e-stop sooner. Nothing really bad happened, but the point was made.
I have milled my first "real part." It is a trim ring for the front of the panel that will be a permanent home for the e-stop and the other buttons and knobs I might need to reach in a hurry.
I have learned some happy news about the performance of mb2hal. I have connected THREE arduinos at 115200baud and my VFD at 19200 baud and I am getting about 20Hz updates. Each of them transfers 10 bytes in and out. This suggests to me that I have the option of sprinkling them around the machine as distributed I/O. I think that I will need to have some heartbeat monitoring of them and probably put the machine into feed-hold if there is some sort of problem. It would also make sense for each of them to have an identification number so the machine could identify that they got enumerated differently and not go nuts.
2017-02-05 Great Progress
The touchscreen seems to be broken. I get basically the same coordinates back for any place on the screen I touch it, which I think is a classic sign of a dead digitizer. I couldn't really figure out how to force it to use other drives since it doesn't show up as a serial port like it used to, but since the same values keep coming back with just a little noise, I have declared it dead (at least to me).
The good progress has been that I connected the power drawbar to a linecord and it has tested out. I also successfully got the super cheesy ebay parallel port card recognized under linux (lspci -v, thank you). I also screwed the hinge brackets to the new PC and got the mill up and running under 2.7 instead of 2.6. New hardware, updated OS, new parallel port card... I connected the Z-stepper to the Z-drive. I mounted two monitors on the arm for the machine. I made a stand for the keyboard and mouse. There are a lot of elaborate arms for supporting a monitor and keyboard, but the common failing for all of them is that they are big, expensive, and always in the way. Since I have accepted they were going to be in the way anhow, it seemed like a great simplification to make a "music stand" for the keyboard so it would always be at a comfortable height and light enough I can put it anywhere it is convenient. That seemed like a great benefit.
I could not resist the temptation to play, so I used inkscape to make a sign,dxf2gcode to turn it into paths, and then linuxCNC to carve it out of wood as a test. The mill can move really fast if it wants to. Everything went fine, but I need to get my physical control panel with convenient e-stop and pause switches made immediately. Limit switches would be really nice too and would save the machine some self torture.
I have started to use github for managing my machine's configuration files. I have two reasons for doing this. The first is that I like to create reproducible work, and github is a great way to publish that work. I need the practice, so that I can become a real contributor to linuxCNC. Second, it is a good way to recover when my machine inevitably bites the dust, or I mess something up.
The automation of the oiler signal is done. I made use of this thread https://forum.linuxcnc.org/47-hal-examples/10935-lube-pump#10935 and made liberal use of the concepts there to create the below:
# The oiler works like this: Compare table speed to a small velocity. If it is > the small speed the timer
# is triggered. The timer off delay is set to 60s to keep the relays from bouncing every move. The concept
# and many of the lines are taken directly from the thread, but I changed it positive logic to suite my style
# preferencs.
loadrt comp names=LubePumpComp
loadrt timedelay names=LubePumpOffDelay
addf LubePumpComp servo-thread
addf LubePumpOffDelay servo-thread
setp LubePumpComp.hyst 0.0
setp LubePumpComp.in0 0.001
net moving <= motion.current-vel
net moving => LubePumpComp.in1
setp LubePumpOffDelay.off-delay 60.0
net tableMoving LubePumpComp.out => LubePumpOffDelay.in
net pumpon LubePumpOffDelay.out => parport.0.pin-16-out
2017-02-04 Touchscreen Configuration: Debian Wheezy (LinuxCNC 2.7)
I plugged in my MicroTouch (3M) touchscreen and touching it seems to do random clicking things. Not what I had hoped for. I am hoping this is just a calibration thing. I found some instructions on how to pull in xinput-calibrator from debian sid, but I am afraid of it borking my system. Borrowing from future version repositories is risky. I have had good success in the past with pulling down the sourcecode and building things to make them run on older linux systems. Here is what I have done thus far:
#Cloned the git repository from debian. I googled xinput-calibrator debian sid and followed the white rabbit
git clone git://anonscm.debian.org/collab-maint/xinput-calibrator.git
cd xinput-calibrator
./autogen.sh
make
cd src/
./xinput_calibrator
#voila! xinput_calibrator is running...
2017-02-02 Drawing Updates
I did get the Wago I/O installed on some DIN rail and then I realized I had not updated the electrical drawings since I changed to using the Wago I/O as my strategy for the machine. I didn't have symbols for it, nor wire numbers assigned. Most of the evening was spent adding pages to the drawings for the new IO modules and getting some wires drawn. I did learn that importing the Wago 3D pdf drawings into inkscape allows them to be saved out as dxf files. The dxfs imported nicely into Kicad for creating the footprints for the Wago modules. My library now contains Wago I/O 750 series terminal symbols for both schematics and panel layout.
2017-01-30 Oiler Pumping and X Motor Installed
I had very little time tonight to make much headway here, but I connected power to the oiler and the little piston goes up and down. If anyone knows of a good way to verify oil flow to all of the important parts of a mill, please reach out to me on the linuxcnc forums. Because the oiler runs and has some way oil in it, cleaned the decades of gunk off the X axis motor (it's blue!) and installed it. Everything moves around well enough, although I think I may need to manage my maximum acceleration on the axes to prevent skipped steps with really high travel rates (>60ipm).
2017-01-29 Estop Completion and Custom Fuji Frenic VFD Components
There were several problems I needed to solve today. First, I had no way of using the PC to reset the estop system. An additional sticking point was that the VFD faults whenever an Estop is pressed. That is just the way the drive was born. It says in the manual. Also, the VFD wants counts 0-20000 as input, and I didn't want to glue a calculator on the front of the mill just to figure out how many RPM I wanted it to run (although really, surface FPM, number of cutting edges, and radius would be reasonable inputs, too).
Last, I also mechanically damaged the charge pump circuit, so I had to repair it.
I made a custom board that breaks out the few unused inputs and connects outputs 14 and 16 to a pair of relays on an ebay optoisolated relay module. It has worked out fine; however, the optocouplers are wired such that the parallel port is sourcing current to them, which makes me a little nervous. Not much I can do there without adding a bunch of custom circuitry. The relay connected to pin 14 is used to reset the estop circuit. Another pin would have been a better choice because 14 is initialized high by the BIOS, but it doesn't really matter. Linux CNC initializes it low right before it starts the charge pump. Without the charge pump completing the circuit, the relay can't reset the estop system anyway. I had to create a custom pyvcp button for doing these resets, because I learned the one on the red ball with the X is maintained instead of momentary. The momentary button in pyvcp works just fine.
I created a custom component for the Fuji Frenic VFD. It is SO much easier to do the math in C code to do the spindle speed conversions and scaling than trying to do it in hal. It also handles the bit remapping and packing MUCH easier than doing it in hal. My component takes the FWD, REV, and RESET commands and repacks the bits ready to send over modbus. It also takes user input of the speed variator position and the desired RPM and calculates the number of speed counts to send over modbus. Easy in C. Painful in hal. The custom Estop button on the pyvcp is also tied into the reset bit that goes into this component. One press of the button and estop loop is reset and drive faults are cleared. The only wiring added today was for the Estop reset circuit.
The next steps in the machine's evolution are getting the Wago Ethernet IO mounted and tolerant of faults, getting way lubrication wired and verified, adding in limit switch monitoring, mounting the estop buttons, adding a BIG feed-hold button, mounting, configuring, and customizing the touchscreen, migrating to the target PC...uh...one thing at time....
The surface mount parts are cracking when the charge pump board is put under stress. I am going to try to stop touching the wiring that goes to it, and that should help a lot. I have made a few repairs, replaced a few parts, and reduced the number of screws holding it down. All of the updated files are included in my public google drive folder: Mill Configuration Files
2017-01-28 Estop System Refinements
My e-stop system is all in hardware and just notifies LinuxCNC of its status. I am adding the ability to reset the estop system with a momentary pushbutton in the axis GUI. I have done a bit of wiring and reprogramming of the logic. I use a charge pump that is in series with the e-stop string. This means if at any point my charge pump signal quits at the PC, it triggers a hardware e-stop, just as if I pressed a button. The gecko drives require a 5V input signal for them to be able to receive steps from the PC and to enable the drives. My estop relay interrupts this power to make sure the steppers stop immediately. This is monitored by parallel port 0 line 15. The parallel port line goes straight to emc-enable-in input. This input sets the status of the red ball with the X in it.
net estop-relay-closed => iocontrol.0.emc-enable-in
If I press the "red ball with an X" it turns the output iocontrol.0.user-enable-out to TRUE forever. That isn't really what I wanted for resetting the vfd drive fault that is caused by a forced stop, nor do I want the estop loop reset relay held in forever. I want it to pulse and if I forgot to reset the estop button, allow me to try again. To fix this problem I added a button to the pyvcp sidebar. ESTOP RESET. I made these additions to custompanel.xml:
<button>
<font>("Helvetica",20)</font>
<width>3</width>
<halpin>"estopreset"</halpin>
<text>"ESTOP RESET"</text>
</button>
This created the pin pyvcp.estopreset
Fuji VFD: I learned that pulsing the first bit (of 16, in the drive operation register) over the network will clear the er6 (power loss) fault that I get when I trigger an estop. Power must be restored to the drive before this can happen. I will need to make sure I unlatch the FWD or REV bits before performing this reset to prevent immediate motion from occurring on the spindle.
2017-01-27 Wago 750-920 Programming Cable Pinout
It appears that the header for serial connection to the 750-842 has this pinout
TOP OF BUS ADAPTER
1 Module TX (PC RX) Observed 5V idle state.
2 Module RX (PC TX) Observed 5V idle state and transitions low for the bits during putty keypresses
3 Module 5V out to feed the adapter (voltage present even with Wago cable disconnected)
4 Ground
2017-01-26 Modbus via Ethernet Proof of Principle
I had some Wago 750 Ethernet I/O that I thought would be ideal for handling the miscellaneous I/O for the machine. I recalled that it could use modbus to read and write to it, so it seemed like my success with the serial version of modbus could be extended to work with the ethernet I/O. I was successful, but I learned a few things along the way.
The big 5.3Mb manual from the Wago website is pretty good. It covers the I/O mapping in a fair level of detail.
BOOTP is used to configure the IP address of the I/O. I installed bootp (the bootp daemon). In /etc/bootptab I put this line at the bottom:
banana:ht=1:ha=0030de003207:ip=172.16.0.22:
I ran into a hiccup where it needed a node ID #, so I put in 1. After that, I could read the inputs.
When I tried to write the outputs, I found I could only get the last LED to light. The other ones were flashing. I guessed that maybe there was a program still running in the bus adapter, so I put the switch into the stop position. I was still able to read the I/O and write to the outputs, but now I could light up all four outputs on each module. I am currently reading and writing them as complete 16bit integers. I think I can set them up as individual bools instead to make the easier to assign to things in linuxcnc.
Here is a copy of the working file for proof-of-principle with the Wago 750-842 Bus coupler and LinuxCNC:
Updated 2017-01-25 This morning I got the VFD to send some bytes back to LinuxCNC over modbus. It is super easy, if you get the wires on the screw terminals to conduct electricity. I used an ebay RS-485 to USB converter like this:
I put a 100Ω resistor on each end of of the shielded twisted pair to the drive. I edited a copy of the mb2hal.ini file and asked to read a register. Stuff showed up on some pins. Key Commands I learned for testing mb2hal.
halrun -I
loadusr -W mb2hal config=mb2hal.ini
halrun starts an interactive hal session.
loadusr loads the mb2hal userspace driver and configures it using the mb2hal.ini file I edited.
Here is the modbus configuration file that will allow me to start and stop the VFD and read its status:
To read the values provided by the drive in a little watch window, I typed this:
watch -n 0.2 'halcmd show pin mb2hal'
To set the desired speed of the drive (0-20000 = 0-100% of full speed):
halcmd setp mb2hal.node1.vfd.speedCmd.00 10000
To make the spindle VFD start turning:
halcmd setp mb2hal.node1.vfdOperCmd.00 1
To make the spindle reverse:
halcmd setp mb2hal.node1.vfdOperCmd.00 2
To make the spindle stop:
halcmd setp mb2hal.node1.vfdOperCmd.00 0
NOTE: The numbers reported by hal are in decimal, not hexadecimal.
As of 9:30pm tonight, I can use hal to control the VFD and make it go. I have yet to make it work in the axis gui. I have also tested out my 4th stepper axis since it showed up in the mail today. I now have 3 linear axes and a rotary 4th axis tested. It will be really cool to get the rotary table set up some day.
2017-01-22 E-Stop System/VFD/Stepper Testing and Change of Plans
FUJI Frenic 5HP VFD has not created notable interference. Success!
The E-Stop system works as intended and forces the VFD to an active stop as quickly as possible.
The stepper motors is where the trouble starts. I smoked two of EVAL6480H drives. I have decided to try using a set of Geckodrive G202's with the steppers that came with the machine instead. The science experiment is over. I was impressed that I got the motors to turn at 600RPM, even though they are pretty high inductance. The chip itself appears to be where the drive failed. I do think it would be interesting to try to solder a new chip on them to try to bring them back to life. I do think it would be interesting to try to figure out why running at 70V after about 6 seconds of slow jogging the motors started to stall and then blew the chips. Having said that, I really do not want to wait until next winter to bring my mill into a usable state. Was it supply voltage ripple? Some strange backwards gate capacitance thing coupling inductive spikes into the chip? Gremlins? Maybe some day I will figure it out. I am not sure I even have the equipment to be able to solder on a new chip. It has this big exposed pad under the chip that is soldered to a very effectively heat sinked layer of copper. I put 10 amps through the chip with my bench supply trying to find the fault (dead short), and the thing stayed as cool as a cucumber. Here is a video of the machine running on the EVAL6480H drives before they died. If someone wants to continue where I left off, I am zipping up my repository of files. In the video it is clear that I have working software drivers. The next step was to add advanced diagnostics (skipped step, thermal warning, etc) and then get rid of some sketchy pointer handling and replace it with exported kernel functions
2016-10-18: First coat of paint is on the cabinet now. Rustoleum Smoke Grey a la Harbor Freight HVLP gun.
2016-10-10: Control Cabinet Mock-Up:
This weekend I hung up the control cabinet to see how all the cutouts would line up and then drill and tap a few mounting holes.
2016-09-12: Power Drawbar Details
My machine has an electric impact wrench operated drawbar. There is a pneumatic cylinder that forces the electric impact down to couple its shaft with that of the drawbar. The coupling looks a little like a lovejoy coupling with only metal and no rubber spider. They are sharpened so there is very little chance of the them hitting dead on and failing to engage. I think the box that I have controls the sequencing of the pneumatics and acts as a speed control to limit the torque of the electric impact. My electric impact is an OLD Black and Decker with the handle cut off it and wiring going to the brushes and field winding separately. I was really surprised when I saw that. I would guess that was an aftermarket retrofit.
2016-09-08: At the request of another Shizuoka owner, excruciatingly detailed photos of my machine. Some scanned manuals, too (Thanks, Murray!).
2016-09-07: Solidworks CAD Model now available in the file drawer!
Progress update 2016-02-22 Shizuoka Progress: Hal2Arduino
Charge Pump Circuit I built that e-stops the machine if it doesn't get a heartbeat from the PC.
I am writing a driver for the ST Micro EVAL6480H voltage mode driver IC that allows one to send it command over generic IO like the parallel port. I have a working version of the driver, but it has some cleaning up that should be done before it is "production ready."