OT: Rant: Spaghetti Warehouse

[OkiePC]

Is it just me or is this the worst hack-job you have ever seen?

I tend to believe that Fanuc PalletTool is sort of a turd, but if you R.T.M., you can work with it.

However, the A.P.S. employee who did the attached butcher-ing is hopefully employed as a dishwasher in the Italian restaurant of his dreams.

IF he is still writing machinery control code, I pray that he suffers a "change of heart" and realizes his limitations as a coder.

Thanksgiving is "'round the right angle", so I will only end this rant by giving thanks that the company responsible for this hack-job is out of business *(APS, Advanced Production Systems)

If you are familiar with these jokers, or their employees, please let them know that there is an Okie who is ThankFull that they are no longer in the business of controlling dangerous machinery.

Is this a hack-job or am I wrong? (again)...

Please cast a vote,. do not worry about my feelings, for I have none...simply business...

(see attached...APS customization in yellow, my comments in red, my changes in Turquoise, their changes that result in PRODUCT DAMAGE and risk of injury are enveloped with borders)

This is running on a Fanuc Robot running Handling Tool V 5.3x, and loaded with unit loads via PalletTool v 5.11.

Baby-sitting the Hispanic-Fanuc-In-A-Panic,
Paul

PiEaCe---OUT!

 

[brucechase]

Man, I need to learn robot-speak.

Means nothing to me, but I've seen APS before and not sure if it is the same one. Where are they out of?

By the way, I just got a used FANUC robot and I will be spending a lot of the next year trying to duplicate a task. Never done anything like it before and it should be interesting.

Where do I go to learn ROBOT?

 

[surferb]

lol, I can't tell to what degree you're being serious, but I find it funny anyways. It looks so foreign...

Lines beginning with !s are obviously comments - but what about the text strings in square braces [] that follow colons (preceded by numbers)? Why are there jumps to line numbers that don't exist (ie 100)?

I do agree that a lot of the code appears to be written in spagetti blocks that use techniques similar to 6th grade QBASIC code where the author just discovered GOTO/jump. However, I don't understand what's going on with the code or options that the author had to work with, so I'm not qualified to comment.

In semi-pseudocode:
------------------
00: SWITCH condition
Case 1: goto 10
Case 2: goto 20
Case 3: goto 30

10: increment counter, goto 90
20: goto 90
30: decrement variable, goto 90
90: end
-------------------
Same idea without gotos
-------------------
00: SWITCH condition
Case 1: increment counter
Case 3: decrement variable
90: end

Hopefully you get the idea. I did see some of that. Again, it's really hard for me to say anything because I don't understand even the basics of what's going on - let alone the subtleties.

The code looks pretty cool, though

Man, I need to learn robot-speak.
...
Where do I go to learn ROBOT?

 

[OkiePC]

...Where do I go to learn ROBOT?

Fanuc has some really good training. I have only been to the most basic programming class, but it was quite useful. I learned about PalletTool the hard way, trying to restore one of our old robots following a CPU failure, when our backup SRAM cards were incomplete.

The language used in teach pendant programs is very crude. You only have two choices in SELECT or IF, THEN branching, you can JMP or CALL (Goto or Gosub). So, it makes it impossible to avoid having lots of line labels and jumps.

The text in brackets following a number and a colon is simply a comment.

R[x:comment] is a register (real number). A user variable. There are about 150 of them to work with in my program, and about half of them are used by PalletTool

PR[x:comment] is a position register that holds X,Y,Z,w,p,r coordinates for a robot position. I think there are 90 position register and PalletTool uses the first 50 or so.

Who ever worked on this from APS just added junk to the code to get the three products they produced at that time to stack without position limit errors or crashes. He gave no regard to the possibility that we might one day run products of different sizes and patterns, so his band-aids don't exactly work anymore.

Today, I am still trying to figure out why one of my patches doesn't seem to work correctly during slipsheet placement. I am beginning to think one of the PalletTool functions that returns actual load height is broken, and may have to roll my own. It seems to work fine unless I am placing a slipsheet. Or maybe there is a flaw in my code which eludes me.

Paul

 

[OkiePC]

DOH!

I am such a dipsquit sometimes

I finally figured out after two workdays non-stop studying and testing that I was in the wrong UTOOL_NUM in my RET_CLR program.

Finally today, after rewriting my routine three different ways and still it would calculate a postion about a foot too low, I remembered someting about slipsheet station teaching requiring a certain UTOOL value.

Sure enough the OEM slipsheet and palletplacement programs both change the UTOOL to zero, which means that all future position references and motion put the face of the End Of Arm where I was expecting the face of the vacuum gripper to be...

Well, the good news is, that I have now bypassed a good third of the wasted motion of the APS ****, and all three lanes are safe to run without risk of crashing.

The big problem is with where the PalletTool PLONPAL, PKPALSTK and PKSLPSTK programs end...with the gripper on the units at the pallet. You can't just go from PLONPAL to PKFRMINF without making sure you don't knock down the stack, or the one next to it.

AND FANUC leaves that part for the integrator to program.

Which is a good move, but their structure is conducive to confusion and that is certainly what I had going on these past few days. Yes APS did not put the path logic in CLINFRTN where Fanuc intended, they sprinkled the Parmesan in CALCZPOZ, CLINFRTN, PLONPAL, and several other routines just to get our basic product type functioning which worked without problems until our boxes suddenly got 8 inches taller with a packaging change. now it want to crash after placing slipsheets, especially on its way to the pallet feeder.

So, my first thought when I discoverd this flaw was a band-aid program RET_CLR (Return to Clear) that I can call at the end of PLONPAL, PKSLPSTK and PKPALSTK... all it has to do is get the gripper up and away from the pallet at a height that is safely above the infeed stations. The workcell is arranged so that pallet station 2 is on the far side of pallet station 1, so going to and returing from pallet station 2 require the robot to uses the height of pallet station one as a reference.

I can't figure out why after slipsheet placement my gripper is about 6 inches below the top of a full pallet on station 2 when it needs to swing back. It will hit those boxes. So finally, i decide to refresh my understanding of Tool and Frame references, search through my offline listings and found it.

As embarassing as it is to miss something that should be kind of obvious, hopefully this may help a future PalletTool user...

So, to those of you who may have downloaded my previous attachemnt, insert a line at hte beginning of RET_CLR:

1: UTOOL_NUM=1

and it is fixed...

Paul

 

[surferb]

You guys are hardcore - looks Greek to me.

 

[leitmotif]

Hathan
After your name you have MCSE
What does that stand for??
Been curious for a while

Dan Bentler

 

[CroCop]

Microsoft Certified Systems Engineer

 

[surferb]

yeps, tryin' to remind controls guys that they can provide better services in many cases by working with IT. I find that many "don't know what they don't know" and apply industrial hardware style solutions to software and networking problems (like using a relay to cycle power to reboot a Windows machine - DOOH!). Gotta respect both sides of the house - they're converging.

Microsoft Certified Systems Engineer

 

[CroCop]

yeps, tryin' to remind controls guys that they can provide better services in many cases by working with IT. I find that many "don't know what they don't know" and apply industrial hardware style solutions to software and networking problems (like using a relay to cycle power to reboot a Windows machine - DOOH!). Gotta respect both sides of the house - they're converging.

Eventually, IT & PLC will be pretty much a bundle deal. At the joint I work at, I cross to the IT side of things fairly frequently, & go & see the IT guru about solutions fairly frequently as well.

A great IT guy in house is INVALUABLE.

 

[mrtweaver]

I agree a great guy in IT is an invaluable asset. We have two IT guys at our facility and both are very knowledable, we collaborate on a large number of things including the recent SCADA project we are currently designing and deploying.

Eventually, IT & PLC will be pretty much a bundle deal. At the joint I work at, I cross to the IT side of things fairly frequently, & go & see the IT guru about solutions fairly frequently as well.

A great IT guy in house is INVALUABLE.