Jump to content
OMRON Forums

iannicholson

Members
  • Posts

    20
  • Joined

  • Last visited

Everything posted by iannicholson

  1. We use Turbo Clipper, and it runs fine. Recently we had a need to assign positions on-the-fly to only two (out of four) axes in a coordinate system. So I wrote the following line in my PLC code: CMD"&1X=29.5Y=29.5" I thought this was working fine for several months (it does have the desired effect). Seemingly unrelated until now, we've had several random customers complain that sometimes they were seeing the A and Z axes (not really a cartesian coordinate system in our case) get offset to strange positions. We've been unable to see this happen until last week, when I was told the feature which used the above CMD seemed to cause major problems with motor positioning. The eventual solution for this customer was to re-home both the A and Z axes to correct their positioning, anytime the mentioned feature was used; due to the uncertainty they have essentially abandoned the feature (it is used during a manual-run mode for our machine which isn't usually necessary). What I found, is that the above CMD seems to also reset the positions of axes A and Z to whatever they last homed to (regardless of their current positions), even though they are not directly called out. I found that even if I simply type for instance "X=29.5" in PEWIN32Pro, the A axis position changes to "90.0" (degrees), and the Z axis changes to "0.0" (inches). These axes should not be changing when I tell the X axis to change! I have circumvented the problem by writing a short motion program which issues the following command in place of the PLC CMD: PSET X(29.5) Y(29.5) This does *not* trigger changes on the un-referenced A and Z axes. We have used this code pattern before, but as it seems a little hacky, I was going for something a little in-line. Is this a known issue with the online axis assign {axis}={constant} CMD? Is there something that could be set wrong that would negatively affect the online command but still allow the PSET command to be limited to the axes specified in the instruction?
  2. Having an identical problem to the OP in this thread: http://forums.deltatau.com/showthread.php?tid=956 I'm seeing the following error message, before communications to PMAC Clipper (not Power Clipper) are severed. PMAC TCP/IP The vital circuit was reset by the remote side. Close all connections to PMAC including PMACServer then replug This is happening pretty regularly to one machine, but I've seen the error on rare occasions on other machines. I've tried 3 different Ethernet cables, and a USB-Ethernet adapter in addition to the motherboard's onboard Ethernet port, so I'm fairly confident the physical connection isn't the problem. The watchdog light is not coming on at all, so the card doesn't seem to be losing power. Is anyone else still having this problem? Any other ideas?
  3. We use LabVIEW 2009, 2013, and 2017 with PMAC Clipper and PMAC PCI/Lite, using the (obsolete) PMACPanelPro suite, and it generally works well. Perhaps you have a permissions issue? Modern Windows are finicky with permissions. The Windows registry key that Delta Tau uses for PMAC needs to have read/write permissions for a given user account in my experience (we just set Authenticated Users to Full Control which covers all cases at the expense of a bit of security). Check here: HKLM\SYSTEM\CurrentControlSet\Services\PMAC
  4. We are possibly have an enclosure custom-built for the Turbo Clipper. A similar thread exists for Power Clipper but we have not yet moved on from the Turbo series. Does Delta Tau sell the IMAC or anything similar in the US at this point? I'm also looking to find out what the end-of-life for Turbo Clipper will be. If we design an enclosure I'd like to find out if it would be worth the retooling time needed to switch to Power Clipper now or continue using Turbo Clipper. What is the general price comparison between Turbo and Power Clipper?
  5. We are looking to have an enclosure custom-designed for the Clipper. Does Delta Tau sell the IMAC or anything similar in the US at this point? We are using Turbo Clipper and have not yet moved to Power Clipper.
  6. Unfortunately, I never had time to implement the ActiveX functions and try this out. I believe it may work though.
  7. Great suggestion. And sarcasm ;) I was aware that some functions don't process until the next scan of the PLC, but I wasn't really sure which ones they were. This explains what might be going on here.
  8. I'm using a range of P-variables to store positions (P800..899). I can issue the following online command to zero out all of the P-variables in the range: P800..899=0 This doesn't seem to work in PLC or motion programs, however (it gives a syntax error in PEWIN32Pro). I have tried the following instead: CMD"P800..899=0" This does not give a syntax error, but I'm not confident that it is having the intended effect (I have a customer running the code, so I don't have direct access to PMAC from my shop currently). Is this valid? I assume that I could write a While loop and incrementally write 0 to each variable, but this seems inefficient. What is the recommended method to write a single value to a large range of variables when in a PLC or motion program?
  9. I just had a slightly older machine with a UMAC where our LabVIEW interface was freezing as it was starting, so we switched over to Ethernet (over the phone, no less) and it seems to be working again. I will have to try Ethernet with the couple Clipper users as well. I did have one customer who found a loose terminal at his 5VDC power supply, but so far he's the only one with concrete evidence of that. I think the count is up to three now, but no one has complained in several weeks... I read in the manual that a dedicated Ethernet card/port is required to be used for UMAC (and I'm assuming this extends to Clipper as well). Is this a hard requirement? This will require us to add an additional Ethernet card to each PC we build. Is a USB<->Ethernet adapter asking for trouble in this scenario? If so, we might be able to use the USB adapter for networking and the onboard Ethernet for UMAC/Clipper. Thanks for everyone's responses!
  10. I just had a slightly older machine with a UMAC where our LabVIEW interface was freezing as it was starting, so we switched over to Ethernet (over the phone, no less) and it seems to be working again. I will have to try Ethernet with the couple Clipper users as well. I did have one customer who found a loose terminal at his 5VDC power supply, but so far he's the only one with concrete evidence of that. I think the count is up to three now, but no one has complained in several weeks... I read in the manual that a dedicated Ethernet card/port is required to be used for UMAC (and I'm assuming this extends to Clipper as well). Is this a hard requirement? This will require us to add an additional Ethernet card to each PC we build. Is a USB<->Ethernet adapter asking for trouble in this scenario? If so, we might be able to use the USB adapter for networking and the onboard Ethernet for UMAC/Clipper. Thanks for everyone's responses!
  11. We have a couple of customers whose symptoms seem to tell me that their Clippers are rebooting. Communication is lost in most cases, and we have to kill PMACSERVER (we are still using PCOMM32Pro) or reboot the PC to get communications to resume. But occasionally when this happens, our LabVIEW app doesn't indicate that communications are lost, but every variable that it reads reports "1" as the value. I haven't been able to query a Clipper while it is doing this (they have already recovered from the problem by the time I am told about it), but from the looks of the screenshots I've seen, the PCOMM32Pro driver is returning "1" for every query. Shutting everything down and restarting does seem to fix the problem, until it happens again. Clipper is being used through USB. Windows 7 Pro PCs. Has anyone had this happen?
  12. We have a couple of customers whose symptoms seem to tell me that their Clippers are rebooting. Communication is lost in most cases, and we have to kill PMACSERVER (we are still using PCOMM32Pro) or reboot the PC to get communications to resume. But occasionally when this happens, our LabVIEW app doesn't indicate that communications are lost, but every variable that it reads reports "1" as the value. I haven't been able to query a Clipper while it is doing this (they have already recovered from the problem by the time I am told about it), but from the looks of the screenshots I've seen, the PCOMM32Pro driver is returning "1" for every query. Shutting everything down and restarting does seem to fix the problem, until it happens again. Clipper is being used through USB. Windows 7 Pro PCs. Has anyone had this happen?
  13. I'd like to know this as well. We use the PMAC Panel Pro toolkit for LabVIEW (I realize it is deprecated :P ), and so far the only way I've found to do this is to manually dump motion programs, dump PLCs, dump all the variables group by group, and dump all the coordinate system definitions into a file (we don't use the comp tables, etc). It would be nice if the library already had a function which handles this. I studied the ActiveX library at one point and I didn't see a function for this there either. Perhaps PCommServer2 has something for this? We don't have it yet.
  14. Steve, We are trying to do the "PSET" analogy in our PLC because this axis is in a different coordinate system than the main motion program. This is done to avoid problems closing the servo loop on &1 because this axis does not have a motor. I imagine that we could run a short motion program on the &2 just to do this PSET, but it seems like a lot of overhead. I gather then that the ideal way to make this happen in a PLC is to use the Position Bias register and multiply our position in inches by the current scale-factor to get the proper units? This was the solution that I had decided on, but I was under pressure to come up with a quick fix solution at the time so I haven't tried this. As a side note, do the newer PMACs support a variable in the {axis}={data} command? Seems like a handy feature. Thanks everyone!
  15. Just a follow-up: We were eventually able to work through our issues and put your advice into use. It works great! Thanks! We were trying to use the {axis}={position} notation in a PLC to reassign our position once a flag is triggered. We found that the following would work: CMD"&2B=-35" while this just wouldn't: CMD"&2B=(P100*-1)" ;or CMD"&2B=P100" Can this notation not handle a variable distance to set to? If so, there must be similar way to PSET to a variable within a PLC, correct? In the end, we had to assign a constant to the axis instead of a variable, and make up the difference later. Thanks for all your help!
  16. wenming, Thanks for the info. We have run into another problem so I can't test your suggestion just yet. I will try to follow-up when we get that far.
  17. I have a need to use the JHW port on the Turbo Clipper to read a quadrature encoder input. It seems there is no mention of actually using the JHW inputs in the manuals (it shows how to hook them up, but not how to read them). Can I assign an M-var to the handwheel input(s) and read them like they were motor positions? If it is in the manuals where should I be looking? Thanks!
  18. We have used PMAC macros in one of our projects, but we were using PEWIN32Pro to download the CFG to the card each time we made a change. Recently I converted a different project to use macros, but we have developed an application for automatically downloading these CFGs to the cards. Apparently the PCOMM32 driver does not have the capability to parse the macros when using the API download functionality. As I see it, my two options are: 1) Create a macro parser in my downloading application and handle parsing and translating the macros myself, or 2) Acquire the Delta Tau parser utility and distribute it with the installer Can someone point me to a link to the Delta Tau PMAC Macro Parser utility? Or is there another preferred method? We have not upgraded to the PEWIN32Pro2 suite, so I can't comment on whether this functionality is present in that version. *Edit* After more research, I believe the problem may lie in the DLL functions, but the PCOMM32 ActiveX driver *does* have the capability to parse the macros. We are using PMAC Panel Pro 2 for our projects, and it talks directly to the DLL, so I think that is why it seems to fail. I will try to implement an ActiveX downloading function and see if I can get the macros to work.
  19. [quote='fahmad' pid='786' dateline='1287767637'] Hi Ian, Non-Turbo PMACs' serial speed varies greatly from board to board. For older boards, the default speed is 9600 baudrate. For newer boards including most of PMAC lite boards the default speed is 38400, but speed really depends on CPU type, speed, and jumper settings. PMAC ISA and PMAC PC104 are identical as far as serial communication is concerned. PC104 is essentially an ISA bus. The difference is that PMAC PC104 is set at 38400 baudrat as default. PMAC lite with Flex CPU are also set at 38400 as default while for older boards serial speed is set at 9600 and is adjusted by jumpers as opposed to I variables. In Pewin32Pro and Pewin32Pro2 serial communication is optimally configured at 38400 baudrate and should work fine both with and without checksum. If you have the exact specification then call our customer support or any of software person and we will be able to help solve serial comm. problem. Farooq [/quote] Farooq, Thanks for responding. I have set the card(s) to 38400, and I get reasonable communication to the card(s). Even set this way, I still get timeouts sometimes. I have the timeout set to 3500ms; is this good enough? 3500ms seems like a large timeout period. We are using LabVIEW to communicate to the cards (PMAC Panel Pro 2.0). We just want to know if the serial port will be fast enough to switch over to using serial comms on these older cards in our application. We have several, and they are worth a lot to our customers (many machines dating from the early 2000s), so we hate to end up throwing them away. I expect the ISA bus to be faster, but can you give me any kind of "maximum amount of commands per second" or something similar for RS-232 versus ISA or PCI?
  20. We have a small stockpile of old PMAC Lite ISA cards that should work (I'm actually in the middle of testing them). These cards are mostly (or all) used cards that were returned from customers during troubleshooting or upgrades, and in most cases there is nothing wrong with the card. Since ISA capable PCs are so hard to find now, we are strongly considering mounting these cards on a homebrew backplane, and using RS-232 to communicate. I have RS-232 communications working on the card on my bench, but I notice that the communication is almost unbearably slow. I removed the E45 and E46 jumpers to set the port speed to 38400, and have changed the port speed in the PCOMM32 settings, but the speed didn't really change. When downloading a configuration to the card, if I choose YES to use checksums, I get a timeout during read of every 100th or so PVar. Is this normal with serial comms? Selecting NO to checksums doesn't give me this error, and the download is significantly faster. Any help or past experiences are greatly appreciated. -Ian
×
×
  • Create New...