Unit101 Posted January 4, 2013 Posted January 4, 2013 Is is possible to get the Turbo PMAC Firmware version into a Mvar or Pvar so that it could be read from a Modbus Master ? Is there a register in memory map that holds this value that I could transfer to my own Mvar ? Could be either the "ver" or "eaver" value. Thanks,
Sina.Sattari Posted January 4, 2013 Posted January 4, 2013 I'm not aware of a memory location which we store the firmware number. I believe it is hard coded during the compilation process and it is reported by firmware upon reception of VER or VERS command. One way of implementing this is using of Read/Write an ASCII (PMAC Modbus Address 0xF000) byte stream to and from the PMAC over Modbus by sending a VER command to PMAC over Modbus. How the ASCII Communication Works? The Client master will send an ASCII NULL terminated string with a PMAC Modbus Address address of 0xF000 with the word length of the ASCII string. The Modbus processor will send this ASCII string terminated with a CR to the Host port and wait for a response. The response will be put into a Modbus ASCII holding buffer that can be read by the Client master. If it sends a FC=23 (Write/Read), the string will be sent and the response will be returned in one Modbus command. If a FC = 0x10 (Write Multiple registers) is sent, the response will be put into an internal response string that can be read later with a FC = 3 (Read Multiple registers).
Dan1223 Posted January 4, 2013 Posted January 4, 2013 Sina, Is there a way to use the command buffer to issue the ver command from a plc and have the output redirected into an M-Var or P-Var? Ideally i would like to log the firmware version on power up in plc 1 and store them in variable space. This will allow me to verify that the firmware version are correct before allowing the machine to run.
Sina.Sattari Posted January 5, 2013 Posted January 5, 2013 Dan, The only way I can think of is to issue a CMDA"VERS" in your PLC. The output of this command will be sent to the auxiliary serial port. The response to this command lets say "1.947" characters are stored in the auxiliary serial port register and then they will be transferred to the device connected to auxiliary serial port. In this case, we are not interested in the transfer process and we are only interested in the response characters stored in the auxiliary serial port output buffer, which can be accessed with M-variables and converted back to firmware version. Here is an example code: close end gat del gat // Pointers to auxiliary serial port output buffer characters // Assuming default settings for I0..4 parameters #define integer M1000 #define decimalpoint M1001 #define tenth M1002 #define hundredth M1003 #define thousandth M1004 integer->Y:$1A01,0,8 decimalpoint->Y:$1A02,0,8 tenth->Y:$1A03,0,8 hundredth->Y:$1A04,0,8 thousandth->Y:$1A05,0,8 #define FirmwareVersion P1000 #define timer I6612 open plc 1 clear cmda"vers" timer = 100 * 8388607/I10 // time-out timer while (timer>0 and decimalpoint!=$2E) endwhile if (decimalpoint!=$2E) FirmwareVersion=-1 // timed out else FirmwareVersion= (integer-48)+(tenth-48)/10+(hundredth-48)/100+(thousandth-48)/1000 endif disable plc 1 close
Unit101 Posted January 5, 2013 Author Posted January 5, 2013 Boooyah ! R u the Man or WAT ! Will try this out and report back... As we say down south... "more than one way to skin a pole cat" *** I tested your code and worked exactly as described and expected. - my test was with a Turbo PMAC EthUlite + 2x Yaskawa SigmaV with 85M MACRO ring -I added 2 attachements: 1. your code in a simple .pmc text file for download if desired 2. PDF shows code and results screenshot running in actual test thanks for the quick and great support... this is a valuable tip that could be applied to other similar logic needs,GetPmacFwarVersionInPlc.pdfGetPmacFwareVerToPvar.pmc
Dan1223 Posted January 7, 2013 Posted January 7, 2013 Thanks Sina, I figured there should be a way to use the command buffer I just didn't have the time to figure out how.
curtwilson Posted January 7, 2013 Posted January 7, 2013 Here is an old application note that uses the same technique for a similar purpose - to obtain the electronic ID number internally for use as a software dongle. Accessing Electronic ID Number Internally Most Turbo PMAC controllers have an electronic identification (ID) number module installed. This module provides a unique 64-bit ID number. The intent of this module is for a host computer to be able to identify a particular Turbo PMAC for purposes such as ensuring software has been properly licensed for use on an individual system. The host computer issues the IDNUMBER command and Turbo PMAC responds with a 16-digit hexadecimal ASCII string representing the 64-bit ID number. Note: Turbo PMAC controllers utilizing the “Flex” CPU design employing the “ball grid array” (BGA) package for the processor (no visible pins for the U1 IC) have the ID number module installed standard. (If the 160 MHz Options 5E0 and 5E3 are available for your design, it is a Flex CPU and you will always have the ID number installed.) In virtually all Turbo PMAC configurations, the Flex CPU design has been used since 2003. In older CPU designs, where the processor at U1 is in a “quad flat pack” (QFP) package (with pins extending out all four sides), the ID module did not come standard – Option 18A or 18B had to be ordered. In these designs, the module looked like a large watch battery, and inserted easily into the provided socket on the board. Delta Tau no longer provides this component, but it is still available from the manufacturer. The part is the Dallas Semiconductor (now part of Maxim) DS1990A. Installing this component in the socket is easily done without tools in the field. It was not intended for this ID number to be accessed internally by Turbo PMAC software, but some users have requested this capability. This application note shows how that can be accomplished. It uses a PLC program to issue the IDNUMBER command and direct the response to an unused communications port. It then accesses the “response queue” character by character to assemble the ID number into a single value. ID Number Evaluation Program The following PLC program permits Turbo PMAC user code to access the ID number by telling it to report the number as a hexadecimal ASCII string to the auxiliary serial port. For this program to work, nothing should be trying to read the auxiliary port at the time this program executes. There is no need for the optional auxiliary port interface hardware (Option 9A) to be present; all we are interested in using here is the response queue in RAM, which is always present. Using indirect addressing techniques, the program works through the ASCII response in the queue character by character, reassembling the numerical ID value. This program uses the last 8 hexadecimal ASCII digits of the response to assemble a 32-bit numerical value in a (floating-point) P-variable. More or fewer digits could be used. If only 6 digits were used, the result could fit in a 24-bit fixed-point register for faster subsequent processing. Remember that Turbo PMAC’s mathematical processing for user programs employs a 36-bit mantissa (35 bits plus sign), so that it cannot directly provide exact representations of values longer than 36 bits. CLOSE ; Pointer variable definitions #define AuxRespPtr M4095 ; Address of aux port response AuxRespPtr->Y:$000034,0,20 ; Holds address of latest response #define CharAscii M4096 ; ASCII value of individual char CharAscii->Y:$001A00,0,8 ; Tentative definition, will change #define CharAddr M4097 ; Address of individual character CharAddr->Y:$005000,0,20 ; M4096 definition address #define AuxPortXmit M4098 ; Auxiliary port transmit ready AuxPortXmit->Y:$000030,11 ; Internal control bit ; General-purpose variable definitions #define WaitCycle P4094 ; Background scan counter #define CharNum P4095 ; Number of character in ID value #define CharLsbVal P4096 ; Value of character in ID value #define CharVal P4097 ; Numeric value of character #define IdNumVal P4098 ; Numeric value of ID number string ; Required I-variable settings I64=1 ; Precede PLC responses w/ ; PLC program to evaluate electronic ID number OPEN PLCC 1 CMDA"IDNUMBER" ; Response to auxiliary port WaitCycle=0 ; Initialize counter WHILE (WaitCycle < 2) ; Wait while command is exeucted WaitCycle=WaitCycle+1 ENDWHILE CharNum=16 ; Start with last character CharLsbVal=1 ; Digit value multiplier IdNumVal=0 ; Initialize accumulated sum WHILE (CharNum > 8) ; Use last 8 digits CharAddr=AuxRespPtr+CharNum ; Address specific char in queue IF (CharAscii < $40) ; 0 to 9, not A to F, hex ASCII? CharVal=CharAscii-$30 ; Convert to numeric value ELSE ; A to F hex ASCII CharVal=CharAscii-$37 ; Convert to numeric value ENDIF IdNumVal=IdNumVal+CharVal*CharLsbVal ; Add into sum CharNum=CharNum-1 ; Look at previous character CharLsbVal=CharLsbVal*16 ; Value for this character ENDWHILE AuxPortXmit=0 ; Clear aux port response queue DISABLE PLCC 1 ; So will not run again CLOSE The intent is for this algorithm to run once immediately on power-up/reset to calculate the numeric ID value for later use. It uses a compiled PLC program to make it difficult for a user to figure out what is being done. Sample Key Evaluation Program The usual purpose for accessing the electronic ID number is to compare it to a special matching numeric “key” value. Only if the comparison is proper will a piece of value-added software run. The Turbo PMAC user would provide the software vendor with the ID number, and the software vendor would then provide the numeric key to the user, who would download it to the Turbo PMAC and save it. In operation, the software would process both the ID number and the key, evaluating them for the proper relationship before running. There are several important attributes a good key generation and evaluation scheme must have: • The relationship between the ID number and the key value must not be obvious. • There must be enough unique potential key values that it is impractical to find a matching key value by “brute force.” • The evaluation of the relationship of the key to the ID number must be fast enough not to have a negative impact on the process. • The evaluation algorithm must not be practically discoverable by the user, so he cannot reverse-engineer the key-generation algorithm. This example provides a very simple scheme that basically provides these attributes. It does not purport to be an optimal or most robust possible routine, but to illustrate simply how the fundamental required attributes can be provided. The example employs modulo (remainder) arithmetic, which is widely used in fields like encryption because it is fundamentally not reversible. The key is generated from the numerical ID number according to the following equation: In this equation, the % character is the modulo operator. Div1 and Div2 are integer values of about half the bit length of the used portion of the ID number. (If we use 32 bits of the ID number, these would be about 16-bit values.) They are often prime numbers, but do not have to be. The ^ character is the bit-by-bit exclusive-or (XOR) operator, and AllOnes is a numerical value whose binary representation is all ones for the length of the ID number. It is equal to 2n-1 for an n-bit number (232-1 for a 32-bit ID number value). Of course, both the key generation algorithm and the Div1 and Div2 factors are kept secret by the software vendor. In practice, the user would provide the ID number (and payment!) to the vendor for a particular Turbo PMAC, and the vendor would then provide the key number to the user. The following program shows how a piece of Turbo PMAC code can use the key value and the ID number to decide whether the protected algorithm will execute or not. (In this example, the protected algorithm is simply the incrementing of a variable.) It is vital, of course, that the user not be able to read this code. Therefore it must be implemented compiled or assembled run-time code, as in the compiled PLC program of this example. The program checks to see if the variables IdNumVal (which the previous program generates on power-on/reset) and Key (which the user must install and save – in this case in variable P8191) have the proper relationship. It also checks to see that there is a valid ID number module (if not, the reported value is 0). ; Additional definitions #define Div1 43759 ; First 15/16-bit modulo divisor #define Div2 27483 ; Second 15/16-bit modulo divisor #define Key P8191 ; Required user-supplied key ; Protected program OPEN PLCC 2 IF (((IdNumVal%Div1)*(IdNumVal%Div2))^Key=$FFFFFFFF AND IdNumVal>0) ; Protected code goes here P4001=P4001+1 ; Placeholder code for test purpose ENDIF CLOSE
Recommended Posts