iannicholson

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?

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?

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

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?

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.

Unfortunately, I never had time to implement the ActiveX functions and try this out. I believe it may work though.

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.

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?

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!

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!

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?

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?

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.

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!

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!