Firmware Version into Mvar or Pvar ?

[Unit101]

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]

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]

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]

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]

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

GetPmacFwareVerToPvar.pmc

[Sina.Sattari]

Thanks Unit101.

[Dan1223]

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]

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