kash

Thanks. I also took the opportunity to update my manual from 2012.

Is it possible to read/write the value of an address directly through the Pcommserver.exe? Now, I have a C# program where I am doing something like string plcDisabledBitAddress = "Y:$0031" + plc + ",22"; pmacDevice.GetResponseEx(0, "m8008->" + plcDisabledBitAddress, false, out answer, out status); pmacDevice.GetResponseEx(0, "m8008", false, out response, out status); return response == "0"; which is not optimal for a number of reasons, mainly because m8008 could be used by the user without my program knowing.

I posted a while back a problem with getting interrupts to work with PMAC TURBO 2 PCI Ultralite under Windows 7. There was never a clear resolution to this problem, so I would like to ask if somebody have used interrupts under Windows 7 with success?

It's a custom program I wrote. The PMAC isn't doing anything except gathering (no motors are being commanded etc.), would there still be observable issues? 10000 servo cycles lost corresponds to about 4.5 secs, and I have a timer firing every 250 ms to empty the DPR. So either windows was severely hung, or something else is wrong. It's a bit surprising that the missing data is 10010 and not e.g. 1090 or 440 or some other "more" random.

While gathering the servocycle counter value in the DPR over a period of five days with a gathering interval of 10, I got one occurrence of: 14079776 14079786 14089796 14089806 The bold value is 10010 larger than the previous value instead of 10 larger. What on earth could be the cause of this?

Thank you very much for clearing this up for me.

Unfortunately I already have a user servo running controlling a motor, so writing an extra one is not really possible as far as I know. When you say "set them simultaneously", what exactly does that mean? On the same line in the plc? In the same servocycle? Are the m-variables set immediately? From the documentation it seems as if they go into a buffer for later execution. Is this completely avoided with synchronous assignment (mxxxx==) such that the assignment executes on the next servo cycle?

Cool. Is this true for all variables set in plc0? For instance, my m5001 is wired to an output of a ACC-65E, will setting this first take effect next servocycle such that m89=1 m5001 = 1 are actually synchronized?

It's messing up the order as if some data is being lost. I am using i5000 = 3, so I'm gathering the data in the DPR with wrap around. My host program reads the writepointer position until it is the same in two consecutive reads before I ask for the data. Maybe this is the cause. I will have to investigate further. In the mean time, maybe you know whether setting m89 (assigned to the gathering bit) in single-shot gathering mode (i5049 = 0) will actually trigger gathering at the servo cycle the bit is set, or if it will trigger the gathering in the next servo cycle? Will the gathering bit automatically be set to zero (with 5049=0) after the data has been copied to the DPR?

Grapping the gathering storage point doesn't seem to make much sense. It doesn't change between DPR writes. If I use the DRP writepointer (x:$6044F,24) it messes up the data being gathered. (For some reason assigning an m-variable to this address and then checking on it, is what causes the mess up.)

Thanks. I've been able to play around a while, and when I run my plc0: close i8 = 0 ; Run PLC 0 every servo cycle m100->x:$0,24 ; Servo cycle counter m200->x:$2,24 ; Servo cycle data gathering counter (time) m89->x:$6,19 ; Gathering bit m1001 = 0 open plc 0 clear ; Are we gathering data? if (m89 = 1) m1005 = m200 ; Difference between servo cycle and gathering interval adjusted for servo cycle rollover m1002 = (m100 - i5049) % 16777216 ; Time for next gather cycle? if (m1002 = m200) m5001 = m5001 ^ 2 m1001 = m1001 + 1 endif else m5001 = m5001 & (m5001 ^ 2) m1001 = 0 m1005 = 0 endif close I get the following result from DPR gathering with a i5049=4: m100 m200 m5001 M1001 M1002 M1005 ---------------------------------------------------------------- 8620204 8620204 1 0 8500766 0 8620208 8620208 1 1 8620204 8620204 8620212 8620212 3 2 8620208 8620208 8620216 8620216 1 3 8620212 8620212 8620220 8620220 3 4 8620216 8620216 8620224 8620224 1 5 8620220 8620220 I interpret this as the gathering actually occurring before plc0 is run. The evidence is the first value of m1005 is the default value and it's constantly lagging behind m200. Can this be true? Also, it's strange the m100 is always equal to m200 when gathered in the DPR?

Suggestions noted. Thanks! Why and how is the possible that the actual gathering occurs after the equality? Is it consistent i.e. if it does happen the cycle after the equality, will it always happen the cycle after the equality? Shouldn't the modulo be 16777216 (a '1' less than what you wrote)? Shouldn't m2 also be modulo'ed before comparison with p0?

Thanks for answering guys. My idea so far has been the same as CharlesP suggests, but using X:$000006,19 instead of the GATHER to avoid the background buffer. It is unclear though, if setting X:$000006,19 = 1 will actually trigger a sampling into the DPR and then set X:$000006,19 = 0 afterwards or if I'll have to do this myself? curtwilson's answer seems more elegant though. I will definitely look into this!

I want to gather data in the DPR of my Turbo PMAC 2 Ultralite, but I want the gathering to be synchronized with a digital output from the PMAC. The digital output is an ACC-65E connected to a UMAC which is connected to the PMAC. Preferably I would like the digital output to trigger every time the PMAC puts data into the DPR. Is there a value in the PMAC that indicates that in this servocycle data is sampled into the DPR? Alternatively I could write a plc that will "gather" one sample everytime I set the trigger high. This requires that the "gather" command is not buffered, or at least that it actually is executed at the point in time when it is instructing the PMAC to do so. Can this be accomplished? Are there any other methods of achieving this?

Ah yes. Makes sense. I got it to work now. Thanks!