|
MVI69-GSC: possible problems in the provided PLC program
You need to be logged in to get access to the forums. You can do so here
|
pseudoquas
|
Wednesday 07 September 2005 7:53:46 am |
|
|
MVI69-GSC: possible problems in the provided PLC program
I've identified some problems with the sample program provided for this module. If I am mistaken in any way, by all means respond. Thanks!
1. MainRoutine Task:
Rung 0:
The JSR to ProcessBlock is preceded by a condition that "NEQ Local:1:I.Data[0] -1". However, the range of possible values for this input register apparently(?) are limited from 0 to 127. This precondition should be removed since it will never be false.
2. ProcessBlock:
Rung 2:
This contains a "COP SOURCE: GSC.P1_Data.WriteString DEST: Local:1: O.Data[3] LENGTH: GSC:P1_Data.WriteLength"
However, the WriteLength variable is the number of 8 bit characters to transmit BUT the DEST registers are 16 bit INT. Since the COP Length refers to the number of DEST tags, you will transmit 2X WriteLength characters from the WriteString(8bit) to the O: Data (16 bit). ALSO, WriteLength must not be greater than 25, or you will begin to write over port2 data, starting at O: Data[28]!!!
Next Issue:
WriteLength cannot be greater than 50, because that exceeds the available O:3-O:27 Data space(16 bit INT)! Therefore, tags GSC.P1_Data.WriteString[50-199] can never be transmitted in the program as written and thus should be deleted.
Rung3: "FLL 0 Local:1: O.Data[2] Length 25" should actually be length 26 to fill Data[2-27]. Beyond that, the FLL isn't necessary, since data-write is triggered by a non-zero WriteLength value. If asyncronous capture of old data is of concern, simply flip the COP instructions in Rung 2 so that good data is in place prior to filling in WriteLength value.
Again, if I am off-base in any way, please respond!
Thanks
|
|
jsanders
|
Thursday 08 September 2005 2:00:27 am |
|
|
RE:MVI69-GSC: possible problems in the provided PLC program
Thanks for your comments. We always appreciate this kind of feedback from our more knowledgeable users. We strive to provide the best examples possible; but, sometimes, errors slip through.
1. This comment is valid. An updated version of the sample program deleting the second NEQ of MainRoutine:Rung 0 will be posted to our website soon.
2. This comment is valid. An updated version of the sample program correcting this will be posted to our website soon.
Next Issue:
Again, you are correct. WriteLength cannot be greater than 50. A limit check would help this code. However, it was written with the unstated assumption that it would only be used for strings of 50 characters, or less. The WriteData array could be resized to 50 elements, if the user chooses.
The module supports writing strings longer than 50 characters. This is why the array is larger. We have another sample that shows how to use -1 as the WriteLength and send the output string to the module in successive 50-character blocks. We make this available through Tech Support, rather than the website, as we found it generally just confuses most users.
Good point on the Rung 3 comment about the FLL length and the swapping of the order of COP instructions in Rung 2. We also noticed this and will include it in the new sample. You are correct...a user should always copy the WriteString data to the Output Image before copying the WriteLength, as WriteLength not equal 0 is the trigger to write out the port.
|
|
pseudoquas
|
Thursday 08 September 2005 5:32:35 am |
|
|
RE:MVI69-GSC: possible problems in the provided PLC program
Thanks for the review and the quick response.
|
|
pseudoquas
|
Monday 28 November 2005 8:05:21 am |
|
|
RE:MVI69-GSC: possible problems in the provided PLC program
One other piece of extraneous logic that can be removed:
ProcessBlock: Rung 1
First Instruction on the rung:
GEQ Source A: GSC.Backplane.LastRead Source B: 0
The previous rung COPies Local:1.Data[0] to GSC.Backplane.LastRead. Because Local:1.Data[0] can only contain the data block number [0-127], the GEQ will always be True. Thus, this instruction can safely be deleted.
Sorry for being persnickety, but I get the warm and fuzzies for streamlined code 
|
|
