Jump to content
OMRON Forums

DPR gathering synchronized with digital output pulse


kash
 Share

Recommended Posts

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

  • Replies 17
  • Created
  • Last Reply

Top Posters In This Topic

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

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

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

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

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

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

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

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

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

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

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

Guest
This topic is now closed to further replies.
 Share


×
×
  • Create New...