Ok, cleaned up and booted the Linux box. I knew I was going to do this conversion since I got the machine, so at that time I installed the LinuxCNC/Ubuntu CD on a salvaged Pentium 4 machine. As I have no internet in my shop, I have done no updating. At any rate, so far so good. Let's see if we can figure out the USC's diagnostic program. Naturally I didn't remember to print out the instructions!
Following Jon's instructions, put the file in a place where you can manipulate it. For instance, drag it to your documents folder. The path should be (using a standard EMC2/10.04 bundled install disc from 2010) /home/<username>/Documents. Open a terminal window (applications->accessories->terminal).
type "cd /home/<username>/Documents" and press return. This changed your directory (in the terminal window) to the Documents folder.
Now execute Jon's first command to unpack the file (tar xzvf univstepdiags.tgz)
If you still have the Documents folder open with File Browser, you'll see a new folder was created titled "univstepdiag."
From the terminal window, type "cd univstepdiag" to move to that directory. I don't know why, but Jon's second command didn't work for me unless I was in the univstepdiag directory, rather than the Documents directory.
Now type lspci -v and search for a block about the parallel ports. Write down each of the parallel port addresses listed. There is an example in the EMC2 Integrator Manual, V2.5, Chapter 28, Page 201. For instance, mine were 7800, 7c00, and 8000. These are the PCI parallel ports, assuming they're installed. If you have a motherboard parallel port, the BIOS will probably identify the port it's on, but the default is 0x378.
If you haven't already, enter the directory that was created when you unpacked the program by using the 'cd' command.
Now type the command "sudo ./univstepdiags <port address> bus" and you should see one of three things. Either you'll see "unknown" or "No board" under "type" if the parallel port you've tried has nothing on the other end, repeated 16 times with an address location in front of each repetition (0, 1, etc). Once you find the correct address, the board should respond with a board name, etc, on the first address, with the second address blank (because it's taken up by the board), and the others open. That did not happen. Struggling with this one ...
It turns out that the "Load Fail" light is on. Some old documentation on the LinuxCNC wikis (written by Jon, apparently), tells us that Load Fail is when the FPGA (the main processor on the USC) fails to load the code from the PROM chip on startup, and this can be caused by slow rise time or irregular rise on the power in (12VDC) lines. Retried after finding this, and indeed, it occurs again. Tried connecting to a wall-wart (also 12VDC). No issues, even with repeated restarts. Apparently the power supply's capacitors prevent a sufficiently rapid rise. Perhaps we can work out a solution so I don't need separate 115V power & a wall wart. NOTE: Eventually the board wouldn't load, even with the wall wart. It turned out to be a soldering defect. I returned the USC board and Jon fixed it for me immediately. His customer support is first rate! Also, once the defect was repaired, the board would power-up on the 12VDC machine power without issue. This has been tested repeatedly for some weeks, and I have had no issues.
I found that my PCI parallel port has the following information, but it won't seem to respond.
Oxford semiconductor Ltd. OX16PCI954 (Quad 16950 UART)
Subsystem: Siig Inc Device 2090
While working on the parallel port issue (several hours), I found that the Servo thread & base thread responded with 124,679 and 74,622 max jitter, respectively. Not too good! Good thing I'm using hardware timing!
In the BIOS, under "Integrated Peripherals," "SuperIO Device," "Onboard Parallel Port" shows [378/IRQ7] and I changed Parallel Port Mode from ECP to EPP. EPP Mode Select is EPP1.9.
I was unable to find any other information about the PCI parallel port in the BIOS
I switched the parallel port cable to the motherboard port and re-ran sudo ./univstepdiags 378 bus.
VICTORY IS MINE!
It now shows up as:
io addr = 378
parport addr 0x378
Board Addr Type Ver.
0 Univ Stepper 3
2 No Board ff
3 No Board ff
... and so on up to f (f in hexadecimal = 15 in decimal)
OK, this is what we are expecting! Make sure that you're in EPP mode in the BIOS, this would've saved me a ton of trouble. The documentation on this point is a little spotty. Also, try to use a motherboard parallel port, as the drivers tend to have a better (more standards-accurate) implementation of the EPP mode, so they work better (or so I'm told). Some, but not all, PCI parallel ports have a suitable driver. Do some research first on the driver's EPP support, and, if possible, get a testimony from an existing LinuxCNC user. Use the sourceforge mailing list, as this is your best bet for getting an answer from the community.
So I finally get my board working, when I try to call someone and discuss, the cell phone won't dial out. I turn it off and it crashes. ... Well, we can't have it all, can we?! Verizon firmware is apparently highly reliable.
Continuing with the Jon's test process, I ran the commtest step ("sudo ./univstepdiags 378 commtest") and got zero errors after 223,000 test cyles. So far so good. Press Control + C to quit.
Pressed the E-stop button and saw the green light go out on the board. Unlatching it, I got the green light back on. Another test done.
Ran "sudo ./univstepdiags 378 diocontinuous." Checking what inputs I have wired up, I see that DIO 0 inputs responds to the X and Y limits (wired at -X and -Y respectively). Pulling the cover on the Z switches, I can trigger + and - Z but they show up as 1's under DIO 1, pin 1 and 2, instead of 0 and 1 as I might have expected. E-Stop shows up as DIO 1, Pin 7, Quill Decel as Pin 3, and that's all I have wired at the moment. Everything looks good, but DIO 1 Pin 0 must be used for something else. Seems reasonable, and everything is checking out so far. Ctrl+C to quit.
Oh, the comment about switch settings reminds me, I had to look at the switches page on the Pico Systems website to flip one (#9) of the switches "off" (open), but I have to research why that was so I can document the switch pattern. Switches 1-4 are off for open-loop (stepper) use, and I believe 5-8 are for step/dir mode instead of quadrature (wave) output. I forget what 9 & 10 are for, but I have 9 off and 10 on. The documentation isn't 100% clear about "on" versus "closed" but they're the same thing in this case. -- EDIT: Switch 9 should be on. This is only for support of very old Gecko drivers.
Because I have no encoders, we're done with this step! Too bad I didn't get my fuses & relays today or I might have the machine running by this evening (it's already 3:16 PM, and I'll define "evening" as any time before reveille -- ~6AM, like the Air Force does). Final operation tests will have to wait until Monday evening (2 days from now). In the mean time we can get test the setup, jog the steppers, make sure our config is mostly correct, etc.
For some reason SSR1 and SSR8 (machine enable by default, but I'm not using it) are on? Hmm. They weren't on prior to running univstepdiags' diocontinuous test.
Now lets see about configuring EMC2 ... this could take awhile. Fortunately, I downloaded all the sample configs from the Pico Systems' USC page and brought them over to the shop. No internet in the shop slows things down markedly. It's the dark ages! I've always felt that the documentation surrounding configuration has been a bit lacking, though many folks have worked to improve it in the past few years. I haven't really gone through the wizards fully before, but the list of parameters is a bit much for the novice user. Really only helpful once you're trying to add specific inputs & outputs, or adjust certain parameters.
Apparently I'm running EMC2.4.5. I have to get used to calling it LinuxCNC!
Ok, first copy the Pico Systems sample configs from my Mac to the Linux box via flash drive.
Apparently I've accumulated 44 megs of documentation for this project! I'm sure I'm missing some key info, too.
Going through the "EMC2_Getting_Started.pdf" v2.4, I'm up to chapter 6. This tells me to record my machine information. Specifically, they're looking for drive type (G203V), step time (1 us), step space (2us), Direction Hold (200ns), Direction Setup (200ns).
Now (sec 6.5), they're asking for pinouts. Not relevant b/c of the usc board.
6.6 asks for mechanical info. Because this is a BOSS 5, each axis is the same. Because the G203V's have 10 microsteps per step, the steps per revolution = 200 but the microsteps = 10. Motor teeth = 1, Leadscrew teeth = 1 (1:1 timing pulley ratio), Leadscrew pitch = 5 TPI. Therefore, each step = 0.001" and each microstep = 0.0001" (more or less).
Now lets run stepconf wizard. Click forward, then "Modify a configuration." Let's choose Jon's Spindle DAC configuration. Ok, that didn't work because it didn't have a stepconf wizard file in it. We need to review the Integrators Manual to figure out which files are which and which parameters we need to modify.
Because the Integrator's Manual starts with the INI file, that's what we're going to start with.
Before we do this, make a new copy in your /<user>/emc2/configs directory. Name it something unique. I called it "Matts Bridgeport Series 1 Boss 5 with USC." Descriptive enough, but not exactly concise. For some reason, the gedit didn't like the single quote when I typed it in the .ini file so I omitted it. Now open all the config files and choose "Display" instead of run. I used the Spindle DAC sample config because I thought it would be reasonably similar.
We now need to go through the manual and change values line by line to suit our requirements. There's no wizard that I'm aware of for USC boards.
Looking through the .ini file, increase the Version to 1.7 from 1.6 so we can distinguish from the regular Spindle DAC board config.
Update the machine name.
Leave the debug level the same for now.
Jon has the display set to tkemc, which I'll use for now as I have no preference. There are a number of axis parameters discussed in the [display] section which are irrelevant for us at the moment. So far so good, nothing to change here.
I should note that base period is set to 50,000 ns, which is fine. There's no need to be any faster, and frankly, jitter is fairly unimportant thanks to the USC. As I understand it, as long as we get reasonably consistent servo periods, we're good to go because the machine will think it's driving servos. The USC simulates the servos and translates the servo commands into steps and directions in the FPGA, making it able to take a larger chunk of data and use it for longer, if you will. A software stepper relies on every single pulse from the parallel port to make a move, there's no 'batching' the data.
The [HAL] section is where it gets a bit interesting. The halfiles specified are included in the config. Not sure what they do exactly. Maybe we'll figure that one out later.
[TRAJ] - I changed max velocity (in inches per second) to 2.0 from 1.2, amounting to a max velocity of any axis of 120 IPM. For now, we'll try it. I'm not sure if it's achievable.
The TRAJ section also has probe_index and probe_polarity, which have no definition in the integrator manual. We'll leave them be for now.
For the Axes, change the max velocity to 2.0 from 1.2 for Axes 0, 1, and 2 (X, Y, and Z). No need to mess with Axis 3 (A) because I don't have one at the moment.
Based on the descriptions under homing, this config assumes you have no home switches. While that's technically correct (as I plan on using the limit switches), I'll leave it as is for now. I don't need to home to test stepper functions. Chapter 4 covers homing in more detail, so I can look at it later.
The Deadband setting is .000126" which is just over what the machine can microstep, so I'll leave it as is. I'm not sure how relevant this is.
You see P, I, and D terms these will have to be tuned later. Basically, tune the P up until the following errors appear, then back off a bit (according to Jon). I doubt that feedback loop tuning will be a problem for an open loop system, it just increases the speed & acceleration of each axis.
Input_Scale needs to be adjusted for our system. In our case, we have 2000 counts per rev (with 10 microsteps per step, times 200 steps) times 5 revolutions per inch, so 10,000 counts per inch instead of 4000 counts per inch. Change these on each axis (leaving axis 3 alone for now). I think that's what we need here. It's not entirely clear whether this is what I think it is. I assume instead of encoder counts, we're interested in number of step commands per inch. We'll see when we start jogging the motors.
Ok, now we're done with the .ini file.
Let's look at the univstep_io.hal file.
Chapter 7. The documentation is a bit more ... interesting. More powerful, but more ...
Ok, at the moment we won't eliminate the limits & homes we don't have. In reading chapter 8, we can see that the commands newsig and linksp are deprecated, which means they may no longer be supported at some point.
We can rewrite this using the net command, with no need to define new signals using newsig. At the same time, we'll eliminate the unused home & limit signals. I'm sure this will break something upstream, but we can give it a shot. Some other day, of course.
Toward the bottom of the file, he sets max RPM for the spindle DAC board. Ok, we're not ready to mess with spindle control just yet anyway.
Looking at the other files, the same deprecated commands, but everything appears to be in order. I even understand some of it now, after reading through chapter 7 & 8 of the integrator manual.
Let's run EMC2 and select "Matts Bridgeport Series 1 Boss 5 with USC." It loads, displaying TKEMC. VERY blue.
Ok, I'm switching to Axis because I like the more informative display. Close EMC and go back to the .ini file. Edit by uncommenting axis and commenting out tkemc. tkemc is more 'traditional' in CNC, but I can't say I like it.
Solving Axis Movement Issues
Now, some messing around in axis tells me that I get a following error if I attempt moves greater than 0.001 or so. Lets reduce the P term. Since there's no real feedback, this must have something to do with the USC. Let's try 100 instead of 150 for each of the axes. No luck.
More research indicates that the input scale and output scale must be opposite signs. I made output scale -1.000 for each axis. Have to verify that this makes it move in the correct direction. If not simply reverse both the signs.
Increase P term to 1000 per Jon Elson's comments.
Lets increase the following error (Ferror = 1 instead of 0.010)
Lets increase min_ferror to .010 from 0.001.
Seems to be moving negative when it should be moving positive. Now changing input to -10,000 and output scale to +1.000 for all axes. The machine still moves incredibly slowly in the wrong direction. Changing to positive positive, to see if that fixes it. It does.
Now messing around with P terms seems to have little or no effect.
Corresponded with Jon Elson, he recommends eliminating the Input Scale and Output Scale, and replacing them both with "Scale" set to 10,000.
Ok, attempted to start the machine. Plugged in the wall-wart for the USC, then switched on the mains power to the rest of it. The USC's load fail led is on and the Estop OK LED. I think it was on from when I first plugged in the wall-wart, but I didn't make sure. When I remove 12V, they still glow dimly. I switched off the mains power, same result. I pulled the parallel port cable, and the lights go out. Disconnected the parallel port cable, and plugged in the wall wart. The load fail LED and the EStop OK LED come on. Cycled power repeatedly, same result. Plugging in the parallel port cable and removing power, and the lights go dim again. We did have a few brownouts last night while I was working (thunderstorm) -- maybe that blew something on the USC?
Well, on to other work today.
After a 3 week hiatus, I'm back at it. First, let's reinstall the USC.
Before we can reinstall, let's refit the 24VDC relays to SSR 1 & 2. Install the 100 mA fuses in the fuse positions.
Remember, SSR 3-5 are 24VDC for the brake, spindle speed increase, and spindle speed decrease. I expect the solenoids should require absolutely no more than 1 Amp, so I've got 1 amp fuses at the ready. I didn't look up the part number, but I think it's more like .25 amps per solenoid. If they blow we'll know! Fit the fuses first, then the relays. The relays are PN CMX60D5, 60VDC, 5A capable.
Finally, SSR 6 is the coolant (spray mister) relay, which uses a 5A, 240VAC relay, CX240D5. I'm using a 4A, 250V fuse for this one. Again, the coolant spray mister operates on 120V. While I didn't see a plate rating, I doubt it can be more than a solenoid valve, so it can't possibly require anywhere near 480W.
Installed the board and plugged in all the wires I had disconnected.
Initial powerup loads the code correctly!
Now AXIS won't start. Go back to the .ini file and fix the scale. I changed INPUT_SCALE=10000 to SCALE=10000 and deleted output scale. This was a mistake. Change both INPUT_SCALE and OUTPUT_SCALE to 10000. Problem solved.
Incidentally, I restored the PID values to their defaults, as they worked fine now that the scale issues are resolved.
IT'S ALIVE! Jogging seems to work. However, I moved X successfully repeatedly, but then Y threw an error. Resetting and playing around shows two errors: "Cannot unhome while moving, joint 1" and "joint 3 following error." I need to investigate a bit.
OK, joint 3 is the A axis, which isn't even hooked up. Change "AXES" to 3 under [TRAJ], delete "A" from "Coordinates," delete the 4th "0" from "HOME." Then delete the entire AXIS_3 entry. We can always put it back later.
Open univstep_servo.hal and remove all references to the A axis
Open univstep_load.hal and remove all refs to the A axis
specifically, remove the "addf pid.3.do-pid-calcs servo-thread" line
Open univstep_motion.hal and remove all refs to the A axis
Open univstep_io.hal and remove all refs to the A axis
That did it. Now it'll restart, and hopefully without the errors on joint 3.
OK, no problems there. The default jog speed was 59.5 IPM and the max jog speed is 72 IPM, per the slider bar, but max vel is 120 IPM. Not sure which one is controlling. I was able to jog each of the axes without issue, but speed on the X and Y could be increased. I'll tweak that later, but it seems to rip pretty good. Z makes a bit of noise when it is moving, I may also need to tune the stepper pot on each of the gecko drivers, but that's for another day too.
Configuring Inputs, Outputs, and Initial Homing Experiments
I also noticed that I put the mist on Relay 6, but it's default is to relay 4. I'll have to adjust that in the configs. I also need to get rid of the coolant button as I have no flood coolant. The spindle brake solenoid is already on the proper relay by default. Dumb luck there. I will also need to adjust the 'turn spindle faster' and 'turn spindle slower' buttons to apply power to the appropriate relays rather than adjust the DAC output. For now I'm not attempting to get the VFD to change speed, but only run forward and reverse when commanded. That will essentially replicate the controls I had pre-retrofit, although my inputs are not yet setup either. I can command speed changes, the brake, etc, from AXIS, which will do fine for starters.
Let's try to configure home switches. ... that experiment didn't work (and I had to Estop the machine because it didn't recognize the limit switch as a home input and stop and move the other direction. It didn't stop at the limit because I did configure it to ignore the limit (as required), but failed to correctly configure the home input in HAL. OK, in univstep_io.hal, all of the 'pins' are defined.
I adjusted the axis Min, Max, and Home limits as appropriate. X and Y have only 1 switch for all three, so I simply connected the pins corresponding to min & max limits to the physical pins where I had them wired and noted that in comments in the doc. For Z, Zmax is also home, and Zmin is just Zmin.
Moving on, the default configurations for the SSR's are not all correct, so I'll have to adjust some of them. For instance, I have no flood coolant, so that signal must be disconnected. In AXIS, the button will no longer show up once the pin? is removed from the io.hal file. And at the moment, I'll configure speed increase and decrease to simply control the relays directly, rather than attempt to control the DAC output. Buttons for these functions already appear in AXIS, so there's no need to fool with that now.
This was a simple matter of assigning the speed up and down pins to the correct SSR's (remember, SSR# = Dout.#-1 because the port pins are counted from 0, not 1. Therefore, SSR8 = dout.7, etc).
Need to wire up the last of the connections so that I can run my tests. I need to investigate how I may use physical buttons rather than AXIS buttons to effect spindle brake, spindle start, speed up, and speed down. Remember, we need to make sure that the speed changes aren't implemented until the spindle is running AND that the brake doesn't stay on when the spindle is running! That wouldn't be good at all!
OK, now let's pull wire!
All wires are now run, at least that I have planned at the moment. Spindle encoder is to be developed, so nothing on that, and there's actually no spindle stop button. Other than that, we're good to go!
Configuring the VFD for Direction Control & More Homing
Now I need to reconfigure the VFD to accept external input and make sure that it will run on command. Let's power up the machine again.
OK, for the VFD: Configure A002 to 01 so that it runs forward or reverse upon command from the forward or reverse inputs (digital from SSR1 & 2).
Configure A001 to 02 for right now. This uses the value in F001 (should be 60.0) as the frequency value. Once the DAC is up and running, set A001 to 01, which will make it respond to the analog input from the DAC board. We may also need to mess with max frequency at that point to allow faster than 60 hz operation. No messing with that for now, as we need spindle speed feedback so we know what speed we're actually getting. Once we begin messing with the frequency, the head will no longer reflect the correct speed unless we operate at 60 Hz.
OK, started axis, now that I'm done messing with the VFD. Now it won't boot because of my changes to the inputs. Apparently an I/O pin (i.e. din01 -- the x limit switch) cannot be assigned to multiple signals. We'll just have to change the name of the signal and associate it with all our HAL pins so that it's clear, rather than just assign xminlim to the max and home pins on their own.
Having some trouble getting axis to boot, it doesn't like the default spindle speed increase pin names, nor the ones I found on a website listing all halui pins (spindle.increase). Even though I am not sure, by the description, that that's the pin I want, since I want momentary, not 100 RPM increments (and how would it know that anyway?)
Also, the spindle doesn't seem to run, but the SSR's are switching like they should. The spindle brake is also clicking on and off just as it should.
I attempted to home, but my home zero must be wrong, as it shot back to the limit once it had homed the X. Let's get this figured out before we try the others! It should have gone away from the limit .5" after homing, not into it.
A few things to note about Homing: First of all, make sure your steppers drive the axes in the right directions! Both my X and Y were reversed. You can change A and /A at the Geckos, but rather than do that, I simply changed input_scale and output_scale to the negative of their value. This fixed that, but then it changes the sign of the homing velocity commands. My final results were: Home_offset = -0.15, Home = 0, Home Search Vel = -0.16 (roughly 10 IPM), home latch vel = -0.08 (roughly 5 IPM), Home use index = no, and home ignore limits = Yes. This is the same for X and Y. For Z, I used everything the same except HOME_OFFSET = 0.1, so that we don't lose as much travel, but we're still off the switch. Also, the search and latch velocities are now positive because we did not need to reverse the sign on the scale values. I also dropped the search and latch velocities to half (~5 and 2.5 IPM) because it's a relatively short distance to cover.
It's now good to set up axis homing, once you've tested each of these values. I homed Z first with "HOME_SEQUENCE = 0" then set the X and Y to Home sequence = 1. You can use the same sequence number for multiple axes, but you must not skip any numbers. If you don't want to home an axis (i.e. A), just set it to -1. I homed Z first so that (in theory) if it was left down, it would retract before the others moved, to avoid (or at least somewhat mitigate the risk of) a crash between tool and a workpiece. It may actually be safer to home Z first, then Y, then X, because it's unlikely that you have a setup at the extents of the table. It's advisable to make a habit of moving the machine close to the home position before shutting it down to avoid all of this.
OK, I took some time to troubleshoot the spindle problem. Turns out that you have to wire the Hitachi VFD in "Sink" mode, as shown in the manual. Though Jon assures me that the 60V, 15mA SSR's (really optoisolators) can be run in source or sink mode, they don't work for me. I rewired the VFD so that the "PLC" pin is jumpered to 24V output. Then I wired the "L" (ground) pin to the SSR input. SSR1 and 2 outputs are wired to VFD input 1 and 2, respectively. Reversing the L to SSR input results in bad results (like the spindle running on startup without being commanded to do so, if you have 1 of the two inputs unhooked). NOTE: The polarity of these SSR's does matter. What I really fixed by doing this was the polarity. The actual source vs. sink issue is not the one that causes the problem.
Remember that if you left the machine in backgear, motor forward is reverse at the spindle. We'll have to compensate for this ourselves at this point. Just remember, in backgear, run in reverse to cut!
Ok, one more thing to adjust. Set the software limits for your axes. The MIN_LIMIT should be set to something slightly less than zero because otherwise we'll trip the software limits if the machine homes to zero, even though it's 0.150" from the actual limit switch. In this case, I set X and Y axes to -0.050" and Z to -5. Remember, for Z, we're going negative, not positive, so any movements in the wrong direction are actually positive past zero. For the MAX_LIMIT I set them to the machine's specified travel in that axis (except Z, where I used 0.050 because of the positive/negative reversal thing). I haven't verified that X = 18 or Y = 12 doesn't actually trip the limit switch, but I'll get to that in a bit.
The next thing: Set your max speed by adjusting the [TRAJ] MAX_VELOCITY and [AXIS_x] MAX_VELOCITY to my desired max speed, and [AXIS_x] PID_MAX_VEL to at least 0.05 more than the axis max velocity. Remember, these are in inches per second! I messed around with values, and ultimately settled on 1.7 for X and Y, with 1.2 for Z. This equates to 102 IPM and 72 IPM. I found that higher speeds would occasionally stall the driver. I think it has to do with where the motor is between steps when you command a motion (due to high detent torque with these old NEMA 42 motors) and too rapid a step pulse acceleration. The machine would intermittently run at 120 IPM, but only some of the time. Rather than risk losing steps, I just set them to a tested reliable speed. The Z seems to tolerate less before it stalls. I could always adjust the acceleration rates of the steps later, but this will probably work just fine, and 102 IPM is still FAST! Most of my machining time will be in controlled feedrate moves, so rapid contributes almost nothing to total program time. See the Tormach white paper for why their 94 IPM rapid is sufficient and you'll understand. It's true too. Fitting a toolchanger is the true productivity improver!
NOTE: It turns out that the axis accel values are the real issue here. Defaults are like 15 inches/sec/sec, which is WAY too high for a bridgeport stepper. Values from 2-5 are more appropriate. Then you can adjust the max velocities back up. It's the acceleration that's the problem, not the maximum speed.
Fullscreen On Startup
Now time for a 'nice to have' improvement. Let's configure AXIS so that it starts fullscreen. Thanks to a thread on the LinuxCNC forums, I found the following code snippet. Go to your home file folder. Under "View" click "Show Hidden Files." Now find .emcrc and copy it. Rename it to .axisrc, then open it. Edit the comments with your name, etc. Remove all uncommented lines. Insert the following:
fullsize=maxgeo.split(' ') + 'x' + maxgeo.split(' ')
BAM! Restart axis and you're good to go. Easy Pisi.
Push-Button Spindle Speed Control
OK, now for the last problem. Changing the spindle speed! Kind of a necessity. Keep in mind two things. First of all, I disconnected the air a long time ago. Second, running the speed solenoids while under air pressure without the spindle running is BAD for the varispeed drive. DON'T reconnect the air until we think we have everything working. We'll do a series of tests to make sure everything is working BEFORE we hook the air up so we don't damage anything. We have to learn how to use some of the higher functions of HAL, rather than simply assigning hardware pins to signals, and linking them to hal pins. HAL includes some logic capabilities, so we'll make use of them. Now on to the problem at hand!
I had previously attempted to enable the spindle speed up/down to I/O controller using a commented out snipped from Jon's config. Let's mess with that a bit. Uncomment spindle up and let's see what happens. Restarting AXIS, "error: pin 'halui.spindle.increase' not found. OK, looks like the halui module needs to be loaded using loadusr in the univstep_load.hal file.
Ok, I had abandoned the possibility of getting clickable buttons, and instead used the inputs. After some struggling, I developed code using or2 and and2's to verify spindle either forward or reverse = true, then upon press of the physical button, it would operate the appropriate solenoid. Let's test, now that I've got it to load!
I can hear the solenoids click when the spindle runs forward! That's a good sign.
No clicking on either decr. or incr. when spindle is stopped.
Now let's test reverse. Works fine! Ok, now time to apply air!
OK ... now another finding: The Spindle Brake defaults to on when power is NOT applied! Have to edit the hal code for that one in the IO file. Find the brake section in the univstep_io.hal - this is a good opportunity to update for the new commands. Delete out newsig <signame> and replace linksp with net. This works the same, so it's easy.
Now we'll need to use a not. Go to univstep_load.hal and add "loadrt not count=1" and "addf not.0 servo-thread"
Back in the io file, change the code to read:
net SpindleBrakeOn <= not.0.in
net SpindleBrakeOnOutput not.0.out => ppmc.0.dout.02.out
net SpindleBrakeOn => motion.spindle-brake
This outputs a low whenever motion.spindle-brake is commanded to be on.
Ok, now it works, but the VFD throws an E022 error because it decel's way too fast when the brake is on. Let's see what the manual says ... CPU communication failure? Maybe the timing wasn't ideal. Let's try that again. Trips again. Hmm... Let's see if we can't find the decel settings. It stops almost immediately with the brake on, no need to use any VFD braking.
I have also noticed that the inverter wants to start occasionally, most likely due to noise. It's only enough to turn the motor armature a bit, so I hear a little clunk in the head. I need to get shielded wire for the two motor inputs from SSR1 & SSR2.
Ok, we want "Free Run Stop" enabled, which is parameter b091 = 1. We also want parameter b088 = 01, which detects motor frequency and resumes at that speed (for instance, if we were in free run stop mode, and coasting down, and then clicked to run another direction. If b088 = 0, it would attempt to force the motor to 0 before accelerating it to the desired speed, which would cause an instant trip. However, when I look at the inverter, neither B088 or B091 are available options!
For now, let's disable the brake by adding the 'auto-off' functionality to the hal file and switching the brake option to 'off.' Start by opening the io and load files. We're going to need an 'and2' so increment the load file's loadrt and2 count value by 1. Mine's now at 4. Add a line "addf and2.3 servo-thread" to the load file.
In io.hal, add "net SpindleBrakeAutoIn ppmc.0.din.12.in => and2.3.in0" and add a new net SpindleBrakeOnWithSw (just what I called it) to connect and2.3.in1 and motion.spindle-brake.
Now change SpindleBrakeOn to connect and2.3.out. The new signal (SpindleBrakeOnWithSw) is then notted to produce the output (SpindleBrakeOnOutput) as before so that the spindle brake only goes on when both 'auto' (ppmc din #12) and SpindleBrakeOn from AXIS go high concurrently. Turns out that my sign was reversed, so we actually want to use ppmc.0.din.12.in-not. Problem solved! Works perfectly now, just note that the spindle brake checkbox will still be enabled, but if it's bypassed by the manual switch, it's not going to go on no matter how much clicking you do!
Ok, let's get back to the original point: Testing the speed control!
BINGO, it works perfectly.
While we're at it, we might as well enable the run start buttons, then we're ready to run a program! The only issue here is that when identifying wires, I forgot to isolate a wire that would show spindle stop, so we have to stop the spindle with the click button in AXIS. That shouldn't be a problem because if we need to do it in a hurry, chances are we should be hitting ESTOP anyway. Lacking a brake, it doesn't much matter if it's on, because it'll still take forever to stop anyway.
Correction, we're going to attempt this later, because I need to solve the problem of having an output that I can't update. If the spindle runs but AXIS doesn't update to reflect that fact (similar to the brake situation) that's no good because I won't be able to click "stop" to get it to stop. Of course, I could click reverse direction, then stop, but that's not really kosher.
Update: Fix the VFD by enabling more options!
Parameter b031 must be set to 'high level access,' b031 = 10
Parameter b037 must be set to 'full display,' b037 = 00
Now we want b091, run mode, set to "Free Run Stop" enabled, b091 = 1
We also want parameter b088 = 01 so that the drive resumes at the motor's current speed.
This will fix the spindle braking issue.
I suspect the way to update the AXIS GUI for the brake is to use halui.spindle.brake-off and rewrite the logic a bit. I need to test my theory at a later date, then further investigate the halui pins to determine if a similar set of input pins exist to update the GUI for the spindle direction. I may also be able to enable the spindle speed increase/decrease buttons as momentary switches using the halui pins.
Ok, time for messing with a g-code program. Let's rewrite the drift shell program for the new control.
Let's check that we have the manual toolchanger enabled because I have Kwik-Switch collets and don't need to reset tool height every time. This is in the .ini file. But what is the parameter name? NOTE: No it's not, it's a separate component that must be loaded in the user space, as documented below.
Also need to tune the gecko drivers, per the procedure in the manual.
Looks like we need to put in:
loadusr -W hal_manualtoolchange
net tool-change iocontrol.0.tool-change => hal_manualtoolchange.change
net tool-changed iocontrol.0.tool-changed <= hal_manualtoolchange.changed
net tool-number iocontrol.0.tool-prep-number => hal_manualtoolchange.number
net tool-prepare-loopback iocontrol.0.tool-prepare => iocontrol.0.tool-prepared
That should get the tool-change prompt working so we can start making stuff!
Ok, that worked, as long as I spelled it right - had a minor error with a misspelling.
Ok, some test running shows that it doesn't start the spindle automatically. Either you need to configure the machine so you can start it automatically, or you can insert an M3 (clockwise) or M4 (counterclockwise) with an Sxxx parameter. The S spindle speed doesn't matter if you have no control over spindle speed, but if you don't put it in, the spindle won't run! I put this on the next line after the tool change line and also inserted a pause so I would have time to adjust the spindle speed. This way, the method is insert the tool when prompted and click 'continue.' If you need to shift to backgear, this is the time (and you might want to note that in your code). Then, after clicking ok, the spindle will begin running. Set the speed to whatever you specified in your G-code file (if it was what you actually wanted) and then click "s" or the pause button in AXIS. Now the machine will run. It's a two step process, but it seems to work well.
I also found I had some stalling on the X, Y, and Z axes. They would not move all of the time. I turned down max speed to 1.55 on X and Y, and I'll keep an eye on it. NOTE: As above, the real problem is the default accel with the standard Sigma motors. Turn it to 2-5 instead of 15 for each axis and you can turn the max speeds up again.
Gecko Drive Tuning
Now let's tune the motors per the Gecko procedure in the G203V manual, page 4. It specifies setting the motor to ~1/2 rev/second. This is 30 RPM. If there are 0.200" per revolution (which there are for BOSS 3/4/5 machines), then we're looking at 30 Revs/min * 0.200"/Rev = .2*30 = 6 IPM. Let's home the machine, then do a G1 move at 6 IPM for the full travel of each axis, and have our handy #0 phillips head screwdriver ready to turn the trim pot. Apparently it shouldn't take more than 1/4 turn from its current position to get it right. We're looking for a 'distinct null' which I believe means it runs quietest at this setting. This may also improve reliability for rapids.
Well, doing X, it seems a little quieter, but not dramatically. I can find a spot where it whines a bit less.
Y, seem a bit better ...
Z, I only have 50 seconds here ... ok, this is noticeably quieter, but I have to watch for stalls. Initially, I tried jogging it back to position, and it stalled repeatedly. I think the high detent torque is to blame here.
Put the control cabinet cover back on and cleaned up around the machine. We're almost ready to do some cutting! Two days ago, I ordered a case of each of the filters. The proper sizes are 10x10x1" for the power cabinet, and 25x19x1" for the control cabinet, but 24x18x1" or anything in between will do. A case of 12 will probably last me a lifetime, but hey, they were cheaper that way!
I have a few errands yet to run before I head out for the hillclimb this weekend, so I may have to put off the inaugural machining to next week ... we'll see!
The complete config file package will be attached to the spindle encoder article. If you don't have a spindle encoder, that's not a problem. The machine should still run without it. If not, you can easily extract the offending code. This was a long process and required some time to learn HAL, but overall it makes me far more confident in the ease with which I can adapt LinuxCNC to suit my specific input & output needs. The more I see, the more I like!