Mark-

Hello, Each SCADA/HMI would save to whatever file extension it selected. While a some file extension "can" indicate file data content (i.e. txt, bmp, pdf, etc..) it is not required. A file is just a stream of data bytes. The format can be published or not. This applies to all programs that save data to a file.  Any program can create/save to any extension it chooses. A program could save to a bmp extension and work without any problems. Other programs that use the extension to speculate the file data format would not work with the file. File extensions are only a hint at the file data format.        

Did you ask your instructor/teacher/TA?  

Online translation (not perfect) Is that to say the new at this, but have lots of questions about PLC programming and would villja duskutera this in Swedish with someone knowledgeable in the field!.  

Hello, Floating point values (REAL) are not bit weighted. Floating point values are encoded. Normally, "moving" a float point value to an integer or double integer will fail. Viewing the bits, as an integer, will not give the correct value. Most programming languages provide routines to convert the parts of an encoded floating point value to its parts. For example, a TRUNC command would return the whole part of a floating point value. FRAC would return the fractional part of a floating point value. Some programming languages look at the data type of the destination and automatically convert the floating point value to the correct value based on the destination type. Right, the value must be converted on one end or the other. For example, the four bytes, that represent the floating point value, could be moved into two MODBUS holding register. Now the program reading the MODBUS holding registers would convert the four bytes to a floating point value.    

IIRC, that is the count of elements in the file. IIRC, the first byte of each element is the length byte. It should be one for a single character.  

Yes, but where? In which software program? Are you setting the length byte in the ST register or only putting a value in ST14:1?

Examine them where? The programming software? Change the radix for viewing. The SCADA. which SCADA and "examine them where" in the SCADA?  

I entered "GRAPHIC IS READY BOOT START" in a web search engine and found a few solutions.  

64 hex - C7 hex Vendor Specific

What?

Hello, 0x54 is a forward request open service code.  

A2  Function Code 2    Byte count to read 7    File number 89 File Type FF a two byte element field 96 element  = 150 - low byte 0   element  = 150 - high byte 0  sub element = 0

It should. We have a free DF1 slave simulator. It support the A2 function code. Contact support if it does not work.  

And to add the Weintek packet is OK. The packet specifies the three levels of addressing, the file number (7), the element FF (255) and the sub element 0.

Hello, >is that address is equal to" FF+A7=1A6 hex (422 decimal)" No, from the DF1 protocol manual: Addresses elements 0- 254 only. For higher addresses, setting this byte to FF expands this field to three bytes. Use the second and third bytes for the expanded element address (low address byte first). Just because the address (element field) is not greater than 254 does not mean you can not use expanded addressing. A2  Function Code 2    Byte count to read 7    File number 89 File Type FF a two byte element field A7 element  = 167 - low byte 0   element  = 167 - high byte 0  sub element = 0 As to the Weintek question, I would contact Weintek support for assistance. My2c.    

OK, for me the application was FT and the user programmed part is a project. Mixing the words application/software/valid archive file is/was confusing.

Other way round. Older software would not know newer software data structures/formats/etc.. I would not expect FT 7 to open an FT 8 file. I might expect FT 8 to open an FT 7 file. My2c.

>What do you mean by "If the I/O is automatically mapped" Some PLCs, the I/O is fixed so it is "automatically mapped" to specific addresses. Other PLC you map the I/O to an address which you configure. So configuration is generally <> a PLC program (ladders for example). If you have mapped the I/O to addresses, the PLC should go into run mode without any program, only the correct configuration. As to the message format it depends on serial or TCP. Either way it is a write command.  

Hello, PeakHMI runs on a PC. >Is it possible to control IO without a program in the PLC? It depends. If the I/O is automatically mapped then normally yes. The PLC can be put in run mode without a program.      

Hello, Why not use an HMI ( PeakHMI for example  ) that has all the FINS drivers, create the test code in scripting and generate a report when the test is complete. I am not sure a PLC program is need if you only want to verify inputs and outputs. My2c.    

Hello, PeakHMI might be a good fit.  

Hello, We have a low cost OPC server for Logix. And a low cost HMI.  

It is not a PLC issue. It is a CPU and/or protocol issue. Years ago a colleague and I were working on a project that included communications between two devices. The CPUs were from different manufactures (Motorola and Intel). His was low-high, mine was high-low. Several years later, the another collaboration only his was high-low, mine was low-high.  

Hello, From what I recall the order is "Test". I do know other PLCS are low-high byte when using words for characters. For FINS we support: Format Description 0) Default 1) 2 characters per word, character order high, low – default ABCD 2) 2 characters per word, character order low, high BADC 3) 1 character per word, character in high byte 4) 1 character per word, character in low byte 5) 4 characters per longword, character order ABCD 6) 4 characters per longword, character order DCBA Are you looking at the memory in the PLC or on the HMI?  

Hello Yeah, it is "much like." SRTP has much more overhead and has a session establish handshake after the attach. SNP only the attach IIRC. Also like MODBUS TCP/RTU, the serial protocol has a CRC/LRC and the TCP protocol does not.