Jump to content
OMRON Forums

MatthewDean

Members
  • Posts

    20
  • Joined

  • Last visited

Everything posted by MatthewDean

  1. Chris, Just reformat the first portion of the link like this: ftp://support.deltatau.com/DT-USA/older%20software/pewin32%20and%20NC32/ Nope, that won't work. This forum reformats the link incorrectly. Here it is in quotes to keep the forum from improperly reformatting it: "ftp://support.deltatau.com/DT-USA/older%20software/pewin32%20and%20NC32/"
  2. Richard, This problem seems to occurs on about 1/3 of the GPL201 units that we install. We have had this happen at four separate facilities. They were all on multi-axis machines, so we were able to swap the amplifiers around. The problem always stays with the amplifier. Also, replacing the amplifier always fixes the problem. One thing that we have noticed is that when the motors are sitting still (although still enabled and closed-loop) we don't get the errors. They only show up when there is a decent amount of power going into the amplifiers. Do you know how much current you use during your closed-loop testing at the factory? Thanks, Matthew Dean
  3. Delta Tau, More of the same. We had an amplifier repaired by Delta-Tau and verified as OK. As soon as the customer put it into service, he got the mysterious amplifier fault again. Apparently the factory testing doesn't check for this problem. Is there anything that we can do for this? It seems like a problem that has been around for several years now. Thanks, Matthew Dean Coastal Controls
  4. We are still using a separate PC for our HMI programs. Typically, we write them in C# using Visual Studio. The main benefit that we see from this is that we can use the exact same HMI for the Power PMACs as we use for the non-Power PMACs. The drawback is that we have to purchase a separate PC to run the user-interface. I would be very interested in hearing from Power PMAC users who run their HMI software on the Power PMAC. Thanks, Matthew Dean Coastal Controls
  5. Sina, One of our PowerPMACs requires two consecutive "$$$" commands to reset it properly. After the first "$$$" command it returns to factory default settings with no programs loaded. After the second "$$$" command is has all of our settings and programs loaded. This drove us crazy for a while, but once we figured it out it hasn't been a big issue. Does this sound like the problem you described above? Thanks, Matthew Dean Coastal Controls
  6. JayL, We are having trouble with GPL102, Serial Number: C000B76T. Thanks, Matthew Dean Coastal Controls
  7. Sina, The original RMA was 9001-00586, and the repair information was "REPLACED C160 AND TESTED OKAY" Thanks, Matthew Dean
  8. DT Support, The GPL201 was fixed under warranty. The paperwork says "replaced C160". Now, we have ordered a new batch of GPL amplifiers for a different job and are having the same problem again. This time on a GPL102 amplifier. Should we send it back for repair as well? Thanks, Matthew Dean
  9. Curt, That is what I was hoping you would say. I guess I need to tweak some settings on my PPMAC to get it running faster. My processor usages are actually quite low (25% or so) when I look in the Task Manager, so I think the PPMAC has the speed to handle this. I'm guessing that sometimes the processor gets busy doing other things (like handling host communication?) and it causes a momentary delay which leads to the runtime error. I'll post again when I find the exact problem. Thanks, Matthew Dean Coastal Controls
  10. Delta Tau, How can I avoid conflicts with the Power PMAC's gathered data and my own user data in the shared memory area? I noticed that I can get a pointer to the data using "pSharedMem->Gather.Buffer". Is there a way to tell the Power PMAC beforehand where to store the gathered data? Thanks, Matthew Dean Coastal Controls
  11. Delta-Tau Support, Does anyone have a good feel for the minimum move time we can achieve using the PowerPMAC on a real-world application? We have a 4-axis system that runs in LINEAR mode and uses lookahead. We have our servo rate set to 9kHz and would like to set our TA and TM times as small as possible. Right now we get coordinate system runtime errors when we set them below about 3ms. Does this seem like a reasonable limit, or could we have some other setting on our PowerPMAC limiting us? Also, if this is the limit, what other options do we have for a faster trajectory update? I was thinking about injecting an offset into the commanded position every servo-cyle like we used to do on the old Turbo PMACs. Thanks, Matthew Dean Coastal Controls
  12. What about the ECAT structures? I can't find anything in the manuals about how to access them from a cplc. Is it possible? Thanks, Matthew Dean
  13. Terry, Did you ever find this manual? We are looking for it also. Also, does anyone know if the Power PMAC EtherLite has a watchdog safety circuit? Thanks, Matthew Dean
  14. majidy, I know that this thread is now more than a year old, but did anyone ever complete the EtherCat manual? I haven't been able to locate it. Thanks, Matthew Dean
  15. We fixed the problem by replacing the GPL201 amplifier with a different one. It looks like the original GPL201 was DOA. I'll post an update with details once we get it repaired. Matthew Dean Coastal Controls
  16. We are having trouble with amplifier faults using a PMAC2 and a GPL201 amplifier. We get occasional (every minute or so) amplifier faults back at the PMAC2 board, but they don't appear to be coming from the amplifier. There is no fault code on the amplifier, and we can get around this problem by disabling the amplifier fault checking in Ix25. Of course, this leaves us without an amplifier fault input. Has anyone seen this behavior before? This is a seven axis system, so we have been able to swap around the cabling, Acc8 boards, etc. The problem always seems to follow the GPL201 amplifier. (Note: The other amplifiers in the system are GPL052 and GPL102s. They do not have this problem.) Thanks, Matthew Dean Coastal Controls
  17. KEJR, thanks for the information! It sounds like using Telnet and letting the PPMAC resolve the global names is the way to go. It will sure make the programming easier. This is still sort of an R&D project for us. Our main HMI software is written in C# for Windows machines. So when moving over to the Android we used the SDK (Java) instead of the NDK (C++). I think that it will make the development faster since Java and C# are so similar. We are still waiting to see how this will take shape. Obviously it gives us a low-cost platform with a nice touch interface, but the PPMAC users aren't the type that worry about low-cost. They are looking for high performance. Another thought is that we could make a wireless Android tablet for technicians and engineers to use for plant wide machine diagnostics. Then we could run the actual machines with very simple (or no) user-interfaces for the operators. As for the hardware, we are leaning towards Motorola. I can only assume that they will be around for a while after the merger with Google. We are waiting to see what the successor to the Xoom will look like. Right now I am using my Android phone and the emulator that came with Eclipse. Matthew Dean
  18. Is anyone else out there using the Android operating system for their HMI? Since the Power PMAC Component Library is for Windows machines, we assume that we have to write the communication interfaces ourselves. Right now we have attached a wireless router to the Power PMAC, and then we Telnet in from the Android device. We use the "gpascii -2" command to talk to the Power PMAC. Our questions are: 1. Does this sound like the proper way to go about things? 2. What kind of performance penalty will we see using the "-2" option on the gpascii command to have the Power PMAC resolve the global names for us? Thanks, Matthew Dean
  19. Dave, Can you clarify something for me? When the CPLC programs are missing from the Task Manager, are they still running on the Power PMAC or not? Thanks, Matt
  20. Delta Tau Forum, We are having a similar problem with one of our UMAC CPU Boards (Assy: 603766-102). We can communicate with the board using RS232 communication, but neither the USB nor the Ethernet port will work. When we plug the CPU into the USB port on our computer it is recognized properly, but it will not communicate. We tried running the USB Configuration utility, but the program hangs just before finishing the "Load Boot" task. Is there anything else we can try, or does it sound like our ETHUSB chip is damaged? Thanks, Matthew Dean Perry Automation
×
×
  • Create New...