kash Posted January 9, 2014 Share Posted January 9, 2014 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? Link to comment Share on other sites More sharing options...
Omron Forums Support Posted January 9, 2014 Share Posted January 9, 2014 The gather function of PMAC can only be initiated by the "GAT" command, which is an online command. You have to send "GAT" via a CMD"" command if you are in a motion program or PLC. Therefore, it is not guaranteed to begin gathering at the precise moment your digital output goes high. If you want this sort of synchronization, you'll need to monitor the digital output in a RTIPLC (if you want it to run at the servo rate, set I8=0) and then manually write to memory. I recommend defining a user buffer with the DEFINE UBUFFER command and then indexing through that memory region with M-Variables as you write new values that you want to gather. Please examine page 293 of the Turbo SRM for more details on how to define the User Buffer and where its memory region begins. Or, you could write directly to the DPRAM, depending on what you want to do. Please let me know if you have any other questions about this. Link to comment Share on other sites More sharing options...
curtwilson Posted January 10, 2014 Share Posted January 10, 2014 The key is to use the register at X:$2, which contains the count of the last servo cycle when data gathering was done. This can be compared to the value of X:$0, which is the servo cycle count. Here is a quick setup and test program I just wrote for this purpose: close i8=0 ; Run PLC 0 every servo cycle m0->x:$0,24 ; Servo cycle counter m2->x:$2,24 ; Servo cycle count of last gather open plc 0 clear if (m2 = m0-i5049) ; Time for next gather cycle? p1 = p1 + 1 ; (Action here) endif close Link to comment Share on other sites More sharing options...
kash Posted January 10, 2014 Author Share Posted January 10, 2014 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! Link to comment Share on other sites More sharing options...
curtwilson Posted January 10, 2014 Share Posted January 10, 2014 A couple of notes on my suggestion: 1.) It's possible that the actual gathering occurs the servo cycle after the equality, so you may set a flag in the scan when you see the equality and react to it on the next scan. 2.) Every couple of hours, these registers will roll over, so to be robust, you will have to handle the rollover with "modulo" arithmetic. Try: p0 = (m0 - i5049) % 167772116 if (m2 = p0) ; Time for next gather cycle? 3.) Of course, some time after setting your output, you will need to clear it again to prepare for the next cycle. Link to comment Share on other sites More sharing options...
kash Posted January 12, 2014 Author Share Posted January 12, 2014 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? Link to comment Share on other sites More sharing options...
steve.milici Posted January 13, 2014 Share Posted January 13, 2014 Yes this should be consistent. Yes this is a typo it s/b 16777216. The modulo is only needed on the 'math' to check for rollover - M2 will rollover on its own. Link to comment Share on other sites More sharing options...
kash Posted January 13, 2014 Author Share Posted January 13, 2014 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? Link to comment Share on other sites More sharing options...
curtwilson Posted January 14, 2014 Share Posted January 14, 2014 A simpler way may be just to look at the gathering storage pointer at Y:$3120. In a scan where the value of this register has changed since the last scan, more data has been gathered since the last scan. Link to comment Share on other sites More sharing options...
kash Posted January 14, 2014 Author Share Posted January 14, 2014 A simpler way may be just to look at the gathering storage pointer at Y:$3120. In a scan where the value of this register has changed since the last scan, more data has been gathered since the last scan. 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.) Link to comment Share on other sites More sharing options...
steve.milici Posted January 14, 2014 Share Posted January 14, 2014 I just tried this on my UMAC system and I was able to read the DRP writepointer in both background and foreground without any adverse effects on the gathered data. Please note that only the low 16 bits are valid: X:$6044F,0,16. How is it messing up your data? Link to comment Share on other sites More sharing options...
kash Posted January 17, 2014 Author Share Posted January 17, 2014 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? Link to comment Share on other sites More sharing options...
steve.milici Posted January 17, 2014 Share Posted January 17, 2014 Yes, PMAC will clear the bit after doing the one-shot gather on the next servo cycle. Link to comment Share on other sites More sharing options...
kash Posted January 20, 2014 Author Share Posted January 20, 2014 Yes, PMAC will clear the bit after doing the one-shot gather 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? Link to comment Share on other sites More sharing options...
steve.milici Posted January 20, 2014 Share Posted January 20, 2014 If M89 and M5001 are both set simultaneously in PLC0 then it will set both M-variable values but the data gather will not start until the next servo cycle. If you were to set these in a user servo then the data gather would begin on the servo immediately after the user servo. M5001 would be set in the user servo so these will seem almost simultaneous. Link to comment Share on other sites More sharing options...
kash Posted January 21, 2014 Author Share Posted January 21, 2014 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? Link to comment Share on other sites More sharing options...
steve.milici Posted January 21, 2014 Share Posted January 21, 2014 Simultaneously as on the same line: "M89=1 M5001=1". These variables are set immediately during the execution of the PLC0. These are already in the buffer and executing. Synchronous assignment is for M-variable in motion programs only. Link to comment Share on other sites More sharing options...
kash Posted January 22, 2014 Author Share Posted January 22, 2014 Thank you very much for clearing this up for me. Link to comment Share on other sites More sharing options...
Recommended Posts