nzfm4r123

Thanks Steve--understood on the DISABLE command syntax. Gregs, here are some PEWin32Pro2 watch variables as I run FSW left nest: 1. Left nest successfully welds and starts to jog towards robot unload. -M4018=1 (variable that Visual Studio GUI tells PMAC to jog to robot unload position). -M5002=0 (variable that tells Visual Studio status of PLC26. Status is PLC26 has started). -M4029=1 (variable that tells PLC28 (jog right nest to robot unload) that PLC26 is working). -M15=1 (variable from robot unload controller that it is ready to unload a part from nest). 2. I force open a safety door. Nest stops moving. -M4018=1 -M5002=64 (PLC26 fault. Nest was moving when door opened) -M4029=1 -M15=1 3. I disable robot unload. I don't robot unload to cycle when nest isn't in unload position. -M4018=1 -M5002=64 -M4029=1 -M15=0 4. I close door. Nest does not move. -M4018=0 -M5002=32 (I dont' understand how code gets to this point) -M4029=0 -M15=0 I don't understand why DISABLE PLC26 does not prevent step 4 variables from occurring. Hopefully by renaming the .txt file to .rtf, you can see red-highlights of pertinent code. 20160731 - PLC26_draft.txt

Thanks Steve--understood on the DISABLE syntax. Thanks Gregs. As I run FSW, here are some watch variables: 1. Left nest successfully welds part and starts jogging to robot unload position: -M4018=1 (Visual Studio GUI has enabled robot unload operation) -M5002=0 (This variable communicates PLC26 status to Visual Studio GUI. Zero indicates PLC26 is running) -M4029=1 (This variables tell right-nest PLC28 that left nest is jogging to robot unload position) -M15=1 (This variable tell Visual Studio GUI that robot controller is running robot and that robot is ready to unload left nest). 2. I force open a safety door. Nest stops moving. -M4018=1 -M5002=64 -M4029=1 -M15=1 3. I turn robot controller off. This is prevent robot from trying to pickup part from nest. -M4018=1 -M5002=64 -M4029=1 -M15=0 4. I close door. Nest does not move. -M4018=0 -M5002=32 -M4029=0 -M15=0 Between steps 3 and 4 PLC26 should have executed a "DISABLE PLC26" command. I don't know why PMAC continues executing PLC26 commands. See attached .rtf document. I red-highlighted pertinent section of code.

Hi Tom, and thank you for your response. I had to laugh when I read your post. So simple, but I probably would not have figured it out without your help. Thanks! The machine runs 24/6, so I will try this out on Sunday. Thanks again and regards. John

Hello All, I appreciate your patience as I am a novice when it comes to Turbo PMAC. I imagine this problem will be relatively simple for forum veterans. The attached "DISABLE PLC" command (detailed in Excel spreadsheet) does not work as intended and I hope you can provide some insight as to why. Rather than ceasing execution, the PLC program keeps running after "DISABLE PLC". "DISABLE PLC" occurs if interlocked door is opened during jog command. My first goal is to stop PLC program execution after "DISABLE PLC". My second goal is to offer an alternative path to "DISABLE PLC". I want to physically stop a jog motion if a door is opened, and resume original motion until completion after door is closed. For example if jog motion was 50% complete when interlocked door was opened and then closed, finish jogging the remaining 50%. I use a GeoBrick GBL5-CO-5F2-10S to control a Friction Stir Weld (FSW) machine: six-axis, Turbo PMAC2 processor (80Mhz, 8kx24 internal, 256kx24SRAM, 1MB flash) The FSW machine has two nests, left and right. An operator loads the left nest as the right nest is welding (in a coordinated system PROG14 or PROG15 program) and vice versa. After a successful weld, a PLC program will jog the nest to an unload position where a SCARA robot picks and removes the welded part. If interlocked doors are opened during jog, motion will stop. However, once interlocks are restored, weird things happen because the PLC program kept running as if the jog was not interrupted. I have attached a full configuration backup and an Excel spreadsheet (renamed from .xlsx to .txt) that I hope sufficiently explains what the current code is doing. I highlighted red lines that I think are most pertinent to the problem. I indented the code because helps me keep track of program flow. Feel free to respond if you need additional information. As always I appreciate your help. Thanks! Regards, John john.sabina@gm.com 20160724 - FSW3 Config FULL BACKUP Configuration.txt PLC programs.txt

Hello all, I want to add a variable that acquires variable information from a motion program via DPRAM. I am reading the DPRAM manual, but I am not making much progress in terms of comprehension. Here is an example variable that I hope to replicate once I understand the underlying architecture. I want to create a variable that resolves like "RunningLeftProgram". I attached the associated .cfg file (renamed extension as .txt in order to attach). RunningLeftProgram BOOLEAN: Public Const LeftProgramRunningStatus As Integer = 8 If PMACstatusWord And LeftProgramRunningStatus Then RunningLeftProgram = True DPRAM DEFINITION: pmac.DPRGetLong(dwDevice, &H1438, FatStatus1, status) 'get FatStatus1 DP:$06050E PMACstatusWord EQUATION: ClampFaultStatus = Int(FatStatus1 / &H100000) 'get M5004 clamp fault status FatStatus1 = FatStatus1 - ClampFaultStatus * &H100000 programStatus = Int(FatStatus1 / &H10000) 'get M4012 program status (4-bit max) PMACstatusWord = FatStatus1 - programStatus * &H10000 'M5000 combination status word Thanks for any replies!! I think if I stare at this for a month, it will sink in, but hopefully someone can speed up the process for me. 20140120_FSW3.txt

Thanks for the detailed reply Richard. I will begin working on your suggestions. I will also look into receiving some formal training.

Hello all, A vertical jog sequence doesn't occur consistently, and machine cycle time suffers as a result. I am sure to most on this forum, this will entail basic motor moves 101. I hope you can help me navigate this technical abyss, and set me along the right path to resolution. I know I won't provide enough background information and variable definition, so please feel free to ask for whatever information is needed. I have a GeoBrick, GBL6-CO-5F2-10S, that controls a 5-axes friction stir welder. One axis, Z, drives a ballscrew with a Parker Hannifin MPP0922C1E-NPSN motor that has a 2000-line incremental encoder. The Z-axis (motor 2) has one input--home switch. After welding, the Z-axis should jog in the following manner, as defined by PLC18: move #1. PLC18 jogs in the + direction (typically less than 5mm) until axis reaches value specified in M272 = -102mm. Jog at I222 = 10mm/sec. The typical height range at end of weld is -106 to -105mm. move #2. Once motor reaches M272 = -102mm, PLC 18 executes again and jogs in the + direction until axis reaches value specified by M272 = -50mm. PLC jogs at I222 = 200mm/sec. I don't know if the motor stops or blends between move #1 and #2. This is what happens sporadically: move #1. Welder finishes, and Z-axis starts to jog in the + direction at 10mm/sec. move #2. Z-axis reaches the -102mm height (ascertained by direct observation--I don't have not caught this instance yet in PEWin32Pro2 position monitor), but instead of speeding up from 10mm/sec to 200mm/sec, it continues jogging upward at 10mm/sec. Z-axis jogs at 10mm/sec until it reaches the home switch = 0mm, at which point the z-axis speeds up to 200mm/sec, and jogs in the negative direction down to -50mm. I am wondering if the controller gets stuck in a WHILE(M233=0) END WHILE loop? Here is the PLC18 code: OPEN PLC 18 CLEAR I222=M3991*2.6 IF(P1=1) P1=0 P2=0 IF((M200+200) OR((M200-200)>M272) COMMAND"#2j=*" WHILE(M233=1) END WHILE P2=0 P1000=10 WHILE(P1000>0) P1000=P1000-1 END WHILE WHILE(M233=0) END WHILE END IF P2=1 END IF CLOSE Thanks for your help!

Hi Charles, Thanks for the reply! I will indeed call per your instructions. I look forward to talking in person. I have gotten into the habit of taking a "PEWin32Pro2 Motor 4 Status" screenshot in the event of a motor #4 fault. Of those that I have taken, all indicate a "Bit 3 - Amplifier Fault error". I haven't yet seen a "Bit 5 - I2T Amplifier fault error", but I will certainly pay close attention to that. Thanks again.

Hello all, I hope the forum can point me in a logical direction to better understand amplifier faults. I apologize in advance for my ignorance regarding motion control. I appreciate all inputs. What variables should I track to best understand amplier errors? I support Friction Stir Weld (FSW) machines that use GeoBrick GBL6-CO-5F2-10S (with Turbo PMAC) to control five (5) motors. These motors control gantry systems that support, convey, and weld parts. I support three machines that are approximately 3, 2, and 1 years old. I'll name them FSW1, FSW2, and FSW3, repsectively. They use the same motion hardware and (custom) software. FSW3 is frequently faulting for "motor #4 faults". Sometimes, I encounter five faults per hour. Other times, I encounter one fault per 4 hours. Even idle (i.e., the motor is servoing but is under no load), motor #4 will fault. When a motor #4 occurs, the following things happen: PEWin32Pro2 displays motor status 4, bit 3 "Amplifier Fault" is TRUE. I have not seen other error bits become TRUE. Motor 1 may or may not be operating eratically (short, jerky movements back and forth; makes alot of rumbling noise; motor counts change maybe +/-25). "Amplifier Fault" or other faults have not turned TRUE for motor 1. "Amp Status" LED on front GeoBrick panel may or may not display an intermittent blinking zero. It always displays a blinking dot. Typically, when a motor #4 fault occurs, and motor #1 is "rumbling", the "Amp Status" has a blinking zero. When an error occurs, I initialize Turbo PMAC and rehome all axes. FSW typically resumes running without problem until the next "motor #4 fault". The machine builder first asked that I verify electrical connections. That is done and everything appears ok. I have scheduled downtime to very leadscrew systems. I have moved all axes by hand, and everything is smooth and as expected. Next, the machine builder had me restore the original PMAC configuration file. That is done, and it did not make a difference. Next, the machine builder asked that I "dampen" the tuning a little bit. He advised me to reduce I435 (motor 4 PID acceleration feedforward gain) by 50%. I did, and it did not make a difference. As an aside, Delta Tau tech support did not believe adjusting this variable was appropriate. Next, the machine builder advised me to retune motor #4. I have downloaded tuning documents from this forum, but the whole thing might as well be written in Greek because I understand little. I will ask for assistance from the machine builder. Next, the machine builder advised me to replace the following in order: motor #4, motor #4 cables, GeoBrick. I am in the process of ordering a motor and motor cables. I do have a spare GeoBrick, and I am tempted to replace it and see what happens. Tech support, after receiving the machine configuration file, asked that I verify Hall Sensor operation on motor #4. Per tech support's description, motor #4 hall sensors look ok. One of the forum topics suggesting running a "HallsUVW.exe". I have done that, and it did not make a difference. The tuning .pdf procedure recommends numerous I variables to investigate. If anyone can expound on/advocate certain variables and explain it to me like I'm a fourth-grader, I would greatly appreciate it. [/u]Thanks again for your time and effort.