Jump to content
OMRON Forums

kash

Members
 View Profile  See their activity

  • Posts

    32

  • Joined

  • Last visited

 Content Type 

Posts posted by kash

    Read/write value of memory address directly from Pcommserver

    in Turbo PMAC

    Posted

    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.

    A strange value for the servo cycle counter when gathered

    in Turbo PMAC

    Posted

    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.

    DPR gathering synchronized with digital output pulse

    in Turbo PMAC

    Posted

    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?

    DPR gathering synchronized with digital output pulse

    in Turbo PMAC

    Posted

    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?

    DPR gathering synchronized with digital output pulse

    in Turbo PMAC

    Posted

    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.)

    DPR gathering synchronized with digital output pulse

    in Turbo PMAC

    Posted

    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?

    DPR gathering synchronized with digital output pulse

    in Turbo PMAC

    Posted

    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?

    DPR gathering synchronized with digital output pulse

    in Turbo PMAC

    Posted

    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!

    DPR gathering synchronized with digital output pulse

    in Turbo PMAC

    Posted

    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?

    Problems with issuing commands from a plc

    in Turbo PMAC

    Posted

    I am writing a plc that is supposed to run motors in one direction until the warning following error bit goes high, and then issue a home command on that motor.

     

    I have writting the following, but it does not work as I expect.

     

    open plc1
clear

cmd"#1j-#2j-#3j-"
m7500 = 0
m7501 = 0 
m7502 = 0 
m7503 = 0

while(m7500 < 3)
if (m141 = 1)
	if (m7501 = 0)
		cmd"#1hm"
		m7500 = m7500 + 1
		m7501 = 1
	endif
endif

if (m241 = 1)
	if (m7502 = 0)
		cmd"#2hm"
		m7500 = m7500 + 1
		m7502 = 1
	endif
endif

if (m341 = 1)
	if (m7503 = 0)
		cmd"#3hm"
		m7500 = m7500 + 1
		m7503 = 1
	endif
endif
endw

displc1
close

     

    What typically happens is that the motor trips, because of the fatal following limit is reached, which is 40 times larger than the warning following error.

    It is as if the home command is not always issued.

     

    What could be the problem?

    Calculating the DPRAM gather buffer size

    in Turbo PMAC

    Posted

    I the SRM and User Manual I found that the end of the large DPRAM gather buffer is $603FFF and that the beginning is $060450.

     

    So I should expect my buffer to be $063FFF - $060450 = $03BB0 (15280) long. However, using "define gather" with i5000=3, yields the actual maximum size of 15184, 96 less that my calculation.

     

    What's up with that?

    Not receiving interrupts from PMAC

    in Turbo PMAC

    Posted

    The Executive version is: 4.2.12.2

    OS: Windows 7

    I have only two systems available right now (the third is off running in a field experiment). I have run the "sid" command on the two available systems to obtain the following id's (is that enough?): 6C00000028B59124, D00000001F0AAA27

×
×
  • Create New...