Results 1 to 9 of 9
Thread: Camsoft problem
01-06-2008, 11:47 PM #1
I've got a Camsoft control on a vertical mill with a turret type tool changer. During a tool change the control ignores the turret position limit switches and just keeps spinning. All of the limit switches properly light up the input switches in the panel. The switches were my first guess but it is not going to be that easy.
Now heres the really weird part. After about one minute the Camsoft software just stops and disappears leaving the Windows desktop. The motion control card is left endlessly spinning the turret. All of this started when an employee was doing maintenance on the turret lock and ran the z axis into a piece of wood. I put the wood there just in case. Nothing was mechanically harmed.
Thanks in advance.
01-07-2008, 12:29 AM #2
Is this a servo controlled axis by the Galil card? or at least under analogue control of the card?
As it sound as though either the card command has stopped running and the drive output is still active, or Camsoft has stopped communication with the card, or their is a bug in the turret logic.
Tool changers are very tricky things to write sometimes so it depends on who wrote it.
If it is a hardware problem, either I/O or motion, I prefer to debug with WinTerm or DosTerm, the Galil native command debugger.
If it turns out to be a mechanical problem, then the logic needs some tweeking to cover this happening, (run away).
01-07-2008, 12:45 AM #3
Are you running a new installation? What version of software?
What kind of tool turret are you trying to emulate? Is all the logic written in an Mcode or in a macro?
Have you ever tested your logic by deliberately running onto a limit switch? Can you recover operation in a normal manner?
Have you tried running the Camsoft diagnostic window while doing your test to see if anything shows up? That unexpected crash of the program indicates some kind of a logic error, not so much a simple I/O problem.
01-07-2008, 01:05 AM #4
I didn't do the retrofit so I'm just learning how all this works. The turret tool change worked fine until my employee ran the z axis rapid into the block of wood, although I'm not sure this caused the problem. There are 8 tools and 8 limit switches that make as the turret turns. I've looked at the logic and it isn't very pretty.
!IF t=1 THEN IF #31=1 THEN GOTO :SKIP (tool 1=input #31 etc.)
!IF t=2 THEN IF #30=1 THEN GOTO :SKIP
!IF t=3 THEN IF #29=1 THEN GOTO :SKIP
!IF t=4 THEN IF #28=1 THEN GOTO :SKIP
!IF t=5 THEN IF #27=1 THEN GOTO :SKIP
!IF t=6 THEN IF #26=1 THEN GOTO :SKIP
!IF t=7 THEN IF #25=1 THEN GOTO :SKIP
!IF t=8 THEN IF #24=1 THEN GOTO :SKIP
!MACHGO ;;.48 (z has to be at .48 inches for a solenoid to engage the turret)
!SPINFORWARD (the spindle motor drives the turret)
!BUTTON1 SETON;Spindle Fwd;10;ToggleON
!BUTTON2 SETOFF;Spindle ccw;12;ToggleOFF
!SAY SPINDLE ON
!#39=1 ( I believe this is the solenoid that engages the turret to spin off the spindle motor)
!IF t=1 THEN WAITUNTIL #24=1
!IF t=2 THEN WAITUNTIL #31=1
!IF t=3 THEN WAITUNTIL #30=1
!IF t=4 THEN WAITUNTIL #29=1
!IF t=5 THEN WAITUNTIL #28=1
!IF t=6 THEN WAITUNTIL #27=1
!IF t=7 THEN WAITUNTIL #26=1
!IF t=8 THEN WAITUNTIL #25=1
!SLEEP 5 (I think this is where he attempts to coast to position)
!IF t=1 THEN IF #31=0 THEN GOTO :START
!IF t=2 THEN IF #30=0 THEN GOTO :START
!IF t=3 THEN IF #29=0 THEN GOTO :START
!IF t=4 THEN IF #28=0 THEN GOTO :START
!IF t=5 THEN IF #27=0 THEN GOTO :START
!IF t=6 THEN IF #26=0 THEN GOTO :START
!IF t=7 THEN IF #25=0 THEN GOTO :START
!IF t=8 THEN IF #24=0 THEN GOTO :START
!BUTTON1 SETOFF;Spindle cw;12;ToggleOFF
!BUTTON2 SETOFF;Spindle ccw;12;ToggleOFF
!SAY SPINDLE OFF
The glaring bad part is the guy who did this stops the turret one tool short and coasts to position. If he missed the switch he goes around again. I tried slowing down the rpm but I got the turret stopped midway between two tools. Any help would be appreciated.
01-07-2008, 01:15 AM #5
So there is no geneva wheel or some such contraption to give the index some sort of a dwell period? He's expecting a coasting motor to drift to an exact position?
One observation: there is no 'trap' to catch what happens if a T number less than 1 or greater than 8 is input. You should have a condition to check for this, because the logic will attempt to run with a T number outside of the acceptable range.
I think there is potential for a never-ending loop if the tool detection switches are not being made. I don't know how sensitive each switch is, and whether it stays closed +/- 1 or 2 revolutions of the motor. It sounds like a pretty sloppy mechanical setup, unless it doesn't really matter exactly where the turret stops.
Is there a fixed ratio of spindle turns to turret movement? I'm imagining that you might need to incorporate a method of counting turns (1 ppr) so that more accurate control of the spindle motor on/off can be invented. The Acc/dec ramp of the spindle drive is likely going to be a bit too gentle to give you instant on/off, or how does it look when it runs?
01-07-2008, 07:52 PM #6
The thing is a Burgmaster. It has a driveshaft coming out of the head that has an 8 lobe cam on the end of it that sequentialy makes the switches. There must be some sort of mechanical dwell because it dwells at each tool, although I'm not sure how it does it. The pin on the end of the solenoid must be tapered because if the turret is off a little it will move it into position. All of the mechanicals are enclosed with no easy way to look.
If it doesn't make it to the next tool it will sit in between two tools and the software still justs shuts off. Of course even if it is making it to the next tool the it will ignore the appropriate switch input and endlessly index the turret until the software shuts off, about 60 seconds or roughly 2 complete turret revolutions. But it didn't always do this it was working fine. If I could find the reason why the software just shuts of with no warning it would be a start.
01-08-2008, 12:42 AM #7
What file is this toolchange logic stored within?
It seems to me I may have experimented with the WAITUNTIL command, but found it too flaky because of the interaction of soft logic with hardware events in the Inputio.fil, the results of my tests being that it might wait or it might not. Because the inputs are not monitored continuously but rather at the rate at which the motion card operates (unless you used external high speed I/O on another card).
01-08-2008, 01:57 AM #8
Further thoughts in this: the logic within the Inputio.fil runs every time an I/O event occurs. So you might want to go through that file and make sure that proper traps are set to prevent logic from running inappropriately any time an input or an output are triggered.
Rather than using WAITUNTIL within your toolchange logic, I think it would be better to sense conditions having to do with your tool switches being made/unmade within the Inputio.fil, and write the change of states to variables, then check those variables for retained value within your toolchange logic.
For example if switch #31=1 then capture this within the Inputio.fil with logic like this, (and I've taken liberty to assign a variable at random, but you need to use an available variable. There is a way to check what variable are still available for use):
IF#31=0 THEN \931=0 :EXIT
IF#31=1 THEN \931=1 :EXIT
IF#30=0 THEN \930=0 :EXIT
IF#30=1 THEN \930=1 :EXIT
Extend this list for all switches in all conditions in your I/O. Use the EXIT command after each one to quickly exit the Inputio.fil as soon as the change of state is noted and recorded to a unique variable.
Then, in your toolchange logic, instead of using WAITUNTIL, you can now directly compare the implied state of any switch by checking the variable associated with it. Since the state of variables will reside fixed in memory, you don't have to try to catch a moving switch on the fly, which may not happen with reliability.
01-08-2008, 10:45 PM #9
Thanks for the input. Your advice with the WAITUNTIL makes sense. I'll try it and see how it goes. It still bothers me that the software just shuts off, maybe this will solve the problem.