I have a command file with this format:
31 01 FD 37 04
31 01 FD 37 05
31 01 FD 37 06
31 01 FD 37 07
This commands are in ASCII but i have to send my device same numbers just in HEX
so: 31 01 FD 37 04 -> 31 01 FD 37 04 NOT(33 31 30 31 46 44 33 37 30 34 )
Any idea?
There's a "Hexadecimal String To Number" VI in the palette String -> String/Number conversion. Loop 3 by 3 characters skipping space, and you'll get a nice array of numbers to send to your instrument.
Then, you can convert these numbers to a char array (see numeric conversion palette) and make a string out of it, ready to be written by VISA.
If I understand your question correctly your file contains bytes whose values are 31, 01, FD, 37, 04 etc and you want to send the instrument the string "31 01 FD 37 04". You can do this conversion with a combination of String to Byte Array and Format Into String, for example:
If I've got your question the wrong way round then CharlesB's answer is correct.
You have the file with the correct ASCII characters, so you only need to open the file, read it's contents and forward it to a VISA resource:
Related
i´ve been successfully using a S7 1500 PLC in combination with an SQL-Server for quiete some time now.
I set everything up like mentioned here: S7SQL-Guide-Stackoverflow
Today i tried to add a second parameter to my SQL-Query. So I made something like this:
select Number1,Number2 from MYTABLE WHERE Apple = red and Sky = blue
The S7 sends the telegram, and the SQL-Server replies. So far so good.
I set up the size of TokenColumnMetaData accordingly to my wireshark record,
compiled and send the updates to my PLC.
Now the part which I don´t understand:
I am expecting to receive the value "12345"
so again I used wireshark to see what I should expect:
So what I got is: 39 30 00 00, which is 12345 just the bytes are reversed -no problem so far, but when I check on S7-side, I see this:
My input is shifted by 1 Byte.
How can I solve this?
Unfortantely I don´t have deeper knowledge of the code provided by Siemens for this application.
Edit:
Screenshot of typeUseCaseSpecificTokenrow
Sometimes weird memory stuff happens when the data type comprises an odd number of bytes.
Siemens starts each element on an even memory address. So if Length is at address 0 and Data is at 2-5, then address 1 may be getting the first byte that is intended for Data
Address
Data
Element
00
04
Length 0
01
39
02
30
Data 0, byte 0
03
00
Data 0, byte 1
04
00
Data 0, byte 2
05
08
Data 0, byte 3
06
47
Length 1
07
94
08
03
Data 1, byte 0
09
00
Data 1, byte 1
10
00
Data 1, byte 2
11
00
Data 1, byte 3
12
00
Length 2
13
00
14
FD
Data 2, byte 0
15
10
Data 2, byte 1
16
00
Data 2, byte 2
17
C1
Data 2, byte 3
I basically want to take a time value, convert it into a hexadecimal format value that the webm metadata can read.
Here is an example value:
44 89 88 40 D5 51 C0 00 00 00 00 = 00:00:21.831000000
How would I calculate this, can you provide examples?
It's a 64-bit Double, can be calculated with this: binaryconvert
Input example: 48000 would be 48 seconds flat. 100000 would be 1 minute 40 seconds. Etc.
Output as hex is shown when you convert as binary and read the left side on the site's output.
How can I determine where the MTI start in an ISO 8583 message?
00 1F 60 00 05 80 53 08 00 20 20 01 00 00 80 00 00 92 00 00 00 31 07 00 05 31 32 33 34 31 32 33 34
In that message 00 1F is the length, and 60 00 05 80 53 is the TPDU. (Those aren't part of ISO8583). 08 00 is the MTI. The next 8 bytes are the primary bitmap.
You can buy a copy of the ISO8583 specification from ISO. There is an introduction on wikipedia
position of the MTI is network specific, and should be explained in their technical specifications document.
You can eyeball the MTI by looking for values such as 0100, 0110, 0220, 0230, 0800, etc. in the first 20 bytes, and the are typically followed by 8 to 16 bytes of BMP data
your data shows MTI = 800 with a bitmap = 20 20 01 00 00 80 00 00
That means the following fields are present, 3,11,24,41, with DE 3 (PRoc code) = 920000, DE 11 (STAN) = 003107, and the remaining is shared among 24 and 41, I am not sure about their sizes
In this message a 2 byte header length is used:
00 1F
But some Hosts also use 4 byte header length for ISO 8583 messages. So you can not generalize it, it depends on what you have arranged with the sending Host.
By using WinsCard.dll, I want to use APDU commands to reset PIN code and set a new into the smartcard. But when I launch these commands, I obtain error "67 00" ("Wrong length").
My APDU commands:
// First command, I verify the code PUK (return "90 00")
00 20 00 02 08 36 35 32 34 39 38 37 36
// Second command, I try to set a new code PIN into the card
00 2C 03 01 0C 36 35 32 34 39 38 37 36 31 32 33 34
For second command:
36 35 32 34 39 38 37 36 -> code PUK
31 32 33 34 -> new code PIN
After some searches, the only explanation that I have found is that the "Lc" parameter was wrong. But, in my case, it is equal to "0C", and the length of my data is "0C".
So, I don't understand where is my error.
Have you got an idea?
Thank you very much for your help!
Note:
If I reset the code PIN without put a new PIN (it restores previous code PIN), it works fine:
00 20 00 02 08 31 38 39 30 31 36 39 32
// Reset code PIN
00 2C 03 01 00
Using the RESET RETRY COUNTER command (INS = 0x2C) with P1 = 0x03 means that you want to reset the retry counter without setting new reference data (i.e. a new PIN). If you want to set new reference data (a new PIN) when resetting the retry counter, you could try (depending on what your card supports)
P1 = 0x00 (for the format you tried):
00 2C 00 01 0C 36 35 32 34 39 38 37 36 31 32 33 34
P1 = 0x02 (only the new reference data is sent):
00 2C 02 01 04 31 32 33 34
Your length should be 0x10. Plz refer below example:
A0 2C 00 01 10 3636303535333132 31323334 FFFFFFFF
Command : A0 2C 00 01 10
Input Data : 36 36 30 35 35 33 31 32 31 32 33 34 FF FF FF FF
Output Data : none
Status : 90 00
here 3636303535333132 is unblock key and 31323334 is new pin
I'm trying to read the xref table of a pdf version >= 1.5.
the xref table is an object:
58 0 obj
<</DecodeParms<</Columns 4/Predictor 12>>/Filter/FlateDecode/ID[<CB05990F613E2FCB6120F059A2BCA25B><E2ED9D17A60FB145B03010B70517FC30>]/Index[38 39]/Info 37 0 R/Length 96/Prev 67529/Root 39 0 R/Size 77/Type/XRef/W[1 2 1]>>stream
hÞbbd``b`:$AD`Ì ‰Õ Vˆ8âXAÄ×HÈ$€t¨ – ÁwHp·‚ŒZ$ìÄb!&F† .#5‰ÿŒ>(more here but can't paste)
endstream
endobj
as you can see
/FlatDecode
/Index [38 39], that is 39 entries in the stream
/W [1 2 1] that is each entry is 1 + 2 + 1 = 4 bytes long
/Root 39 0 R that is root object is number 39
BUT :
the decompressed stream is 195 bytes long (39 * 5 = 195). So the length of an entry is 4 or 5.
Here is the first inflated bytes
02 01 00 10 00 02 00 02 cd 00 02 00 01 51 00 02 00 01 70 00 02 00 05 7a 00 02
^^
if entry length is 4 then the root entry is a free object (see the ^^) !!
if the entry is 5: how to interpret the fields of one entry (reference is implicitly made to PDF Reference, chapter 3.4.7 table 3.16 ) ?
For object 38, the first of the stream: it seems, as it is of type 2, to be the 16 object of the stream object number 256, but there is no object 256 in my pdf file !!!
The question is: how shall I handle the 195 bytes ?
A compressed xref table may have been compressed with one of the PNG filters. If the /Predictor value is set to '10' or greater ("a Predictor value greater than or equal to 10 merely indicates that a PNG predictor is in use; the specific predictor function used is explicitly encoded in the incoming data")1, PNG row filters are supplied inside the compressed data "as usual" (i.e., in the first byte of each 'row', where the 'row' is of the width in /W).
Width [1 2 1] plus Predictor byte:
02 01 00 10 00
02 00 02 cd 00
02 00 01 51 00
02 00 01 70 00
02 00 05 7a 00
02 .. .. .. ..
After applying the row filters ('2', or 'up', for all of these rows), you get this:
01 00 10 00
01 02 ed 00
01 03 3e 00
01 04 ae 00
01 09 28 00
.. .. .. ..
Note: calculated by hand; I might have made the odd mistake here and there. Note that the PNG 'up' filter is a byte filter, and the result of the "up" filter is truncated to 8 bits for each addition.
This leads to the following Type 1 XRef references ("type 1 entries define objects that are in use but are not compressed (corresponding to n entries in a cross-reference table)."):2
#38 type 1: offset 10h, generation 0
#39 type 1: offset 2EDh, generation 0
#40 type 1: offset 33Eh, generation 0
#41 type 1: offset 4AEh, generation 0
#42 type 1: offset 928h, generation 0
1 See LZW and Flate Predictor Functions in PDF Reference 1.7, 6th Ed, Section 3.3: Filters.
2 As described in your Table 3.16 in PDF Ref 1.7.