This will give me the correct and expected result. I can now stop the PLC and Activate and on startup go through the insertion of keys and increment a counter using key = ke圓 and state = 20. This would have incremented key1 and key2 by 1 and ke圓 by 2. Now if I increment the counter values by setting key = keyX and state = 20 a few times I get the following. Will yield the following internal table and the secondary counter value table. A_Lookup ( key : = F_DATA_TO_CRC16_CCITT ( ADR ( key ), TO_UDINT ( len ( key )), 0 ), hTable : = hTable ) getValue : = values state : = 31 END_CASEĬurrently done manually on every PLC startup set key = keyX and state = 10 based on the table below and in order to insert the keys. A_Lookup ( key : = F_DATA_TO_CRC16_CCITT ( ADR ( key ), TO_UDINT ( len ( key )), 0 ), hTable : = hTable ) values : = values + 1 state : = 21 30 : fbTable. getValue state : = 11 20 : // We can now directly query the string hash and retrieve the index to get its counter value fbTable. A_GetIndexAtPosPtr ( hTable : = hTable, putPosPtr : = getPosPtr ) // Set the value of the entry to its index inside the array table. A_Add ( key : = F_DATA_TO_CRC16_CCITT ( ADR ( key ), TO_UDINT ( len ( key )), 0 ), putValue : = putValue, hTable : = hTable, getPosPtr => getPosPtr ) // Use the insert adr to find the index used fbTable. PROGRAM MAIN VAR state : INT getPosPtr : POINTER TO T_HashTableEntry fbTable : FB_HashTableCtrl hTable : T_HHASHTABLE table : ARRAY OF T_HashTableEntry key : STRING ( 255 ) putValue : UDINT getValue : ULINT END_VAR VAR PERSISTENT values : ARRAY OF ULINT END_VAR // Implementation CASE state OF 0 : F_CreateHashTableHnd ( ADR ( table ), SIZEOF ( table ), hTable ) state : = 1 10 : // Insert key of all counters on all starts start to repopulate internal representation // Insert into hash table returning the adr of the insert fbTable. That each unique key hash will always result in the same array index. For persistence to work correctly there is an assumption to be made. On every PLC startup the hash table will need to be reinitialized with the same keys. The first workaround is to use the hash to store the index of where inside the internal array a value is stored and use that same index in an external array to store the counter value itself. The second problem of persistence is a little harder to deal with since the initialization function completely clears all the hash table internals. Hopefully the PLC programmer notices that there was a collision and that two key/values are acting weird. TLDR a test using yielded 0.0016% collision rate. There is however a collision possiblity that needs to be taken into account. The first problem can be solved by using the built in F_DATA_TO_CRC16_CCITT hash function to get an UDINT from the STRING. There are two problems that need to be solved here.
This function calculates all the internal pointers needed and also clears the hash of all values. Looking at the example the first thing needed is the initializing of the Hash Table using F_CreateHashTableHnd. This would mean a persistent string hash FB.ĭocumentation for FB_HashTableCtrl here and example here. I was looking at creating an easy to use string key based counter FB that can be set as being persistent to keep track of tool life or part counter on a machine. It uses a DWORD as key and PVOID as value. Creating a deterministic, persistent enabled, HashTable FB which uses strings as keys Introductionīeckhoff currently offers a hash table implementation in their Tc2_Utilities library.
0 kommentar(er)
