MID7.2 Protocol Discussion – Rev 1.01
This the structure of all protocol communications sent to the MID7.2
Byte# | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
E.g. | 32 | 01 | 02 | 02 | 07 | 05 | 00 | 33 |
Desc | STX | ID# | Payload Control | Special Function | Sub OpCode | OpCode | P/Load Length | ETX |
Digital Pumps
Byte# | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
E.g. | 32 | 01 | 02 | 02 | 07 | 05 | 00 | 33 |
Desc | STX | ID# | Payload Control | Special Function | Response Wait | Bytes Expected | P/Load Length | ETX |
These are fix functions that always service the same purpose
Item | Description |
STX | 0x32 |
DeviceID | As per DW1#1-4 |
Payload | Length of the Payload |
ETX | 0x33 |
Packet Control (directs communications from Uart1 to Uart2 or 3) etc
This is actually turning out to be PAYLOAD control. If the purpose was to send the entire Packet to another Uart3, all we need to do is use a different protocol structure that the MID does not recognize and it will send the whole message to the uart it is directing the comms to as it does with all non-wrapped protocols.
So we will call it Payload Control and it gives the Uart that the Comms is delivered to.
| Purpose | Tagging | Keypad/LCD | Mech Pump | Digital Pump |
Payload Control | Directs where the Payload will we used or be delivered | 0x02 (Internal to MID) | 0x05 – LCD1 0x06 – LCD2 | 0x02 (Internal to MID) | 0x03 – Uart2 0x04 – Uart3 (typically = 0x03) |
Special Functions | Double the activities of MID while its servicing other requests | Does not need to be use as these functions are in the SubOpCode 0x00 - Typical vaue | 0x00 | Do nothing | 0x01 | Flash LED1 | 0x02 | LED1 & Beep Tag1 | 0x10 | Flash LED2 | 0x20 | LED2 & Beep Tag2 |
| 0x00 | Do nothing | 0x01 | Flash LED1 | 0x02 | LED1 & Beep Tag1 | 0x10 | Flash LED2 | 0x20 | LED2 & Beep Tag2 |
| 0x00 | Do nothing | 0x01 | Flash LED1 | 0x02 | LED1 & Beep Tag1 | 0x10 | Flash LED2 | 0x20 | LED2 & Beep Tag2 |
|
SubOpCode | Defines the functions of Device Type | 0x00 | Get Status | Status | 0x01 | Clear Device | Clears Tag data | 0x02 | Get Tag Data | Send Tag Data | 0x03 | Short Beep (0.5 Sec | Requesting Tag | 0x04 | Long Beep (3 Sec) | Requesting Acc Tag | 0x05 | Reject Beep (10 x 0.25 Sec) | |
| 0x01 | Initiate Odo type request | 0x02 | Initiate Pin request | 0x03 | Get Odometer type data | 0x04 | Get Pin type data | 0x05 | Gets Menu Prompted data | 0x06 | Prompts for a Yes/No |
| See below | 0x00 | Zero Wait | 0x01 | 10msec | 0x02 | 20msec | 0x03 | 30msec | 0x04 | 40msec |
Wait timeout for Payload |
OpCode | Define the Target Device | 0x04 | 0x06 | 0x05 | 0x03 (Not Really Required ) |
SubOpCode (Mechanical ) OpCode=5 | Description | Function |
0x01 | Get Status | Status |
0x02 | Start Pump | Motor Drive ON |
0x03 | Get Sale Data | Realtime Pulses/ Final sale |
0x04 | Pause Pump | Stops: Motor Drive OFF |
0x05 | Resume Pump | Continue: Motor Drive ON |
0x06 | Get Totalizer * | Get Totalizer Amount |
0x07 | Get Realtime liters | This send the Litres as pumping occurs |
0x08 | Clear Device | Clears Sale & Totalizer data & Clear Preset |
0x09 | Set Price | Sends the price of a liter (Stored in EEPROM) |
0x10 | Set Preset | Send the Preauth amt to limit the liters pumped. |
0x11 | Set Pulse Factor | This tells the controller the number of pulses that equates to a litre. It’s a value like 40 -100 pulses = 1Litre (Stored in EEPROM) |
0x12 | Get Price/Pulse Factor | Gets the Price and Pulse factor |
0x13 | Get Preset | A Read to verify Preset |
0x14 | Set Totalizer | Preset Totes |
0x15 | Set No Pulse Timeout | If no pulses on a Motor ON, it will stop pump |
Response
This the structure of all protocol communications from the MID7.2
Byte# | 1 | 2 | 3 | 4 | 5 | 6 | 11 |
E.g. | 32 | 01 | 01 | 08 | 02 | 00 | 33 |
Desc | STX | ID# | Response Time (m/sec) | Status Byte | Payload Desc | P/Load Length | ETX |
These are fix functions that always service the same purpose
Item | Description |
STX | 0x32 |
DeviceID | As per DW1#1-4 |
Payload | Length of the Payload |
ETX | 0x33 |
Byte 3.
Response Time: Reports back the response time of the Wrapped Protocol response. This information can be use to fine tune the delays for the Digital Pumps.
Byte 4
Status Byte
The Tagging overlaps with Digital and Mechanical Pumps
Mechnical Status Byte | Description | Function |
0000 0001 | Tag1 Data Available | A Tag was just read on RFID1 |
0000 0010 | LCD/KeyPad1 Tasked to do a cycle | This means it is in a process to collect an Odometer or PIN # |
0000 0100 | Keypad is active | Keys are being pressed |
0000 1000 | LCD/KeyPad1 Has data to retrieved | Odo/Pin type data |
0001 0000 | Mechanical Pump Noz UP (Requesting) | The Nozzle has been picked up. |
0010 0000 | Mech Pump Dispensing (Motor ON) | The Pump has been authorized |
0100 0000 | If the Pulser is Active | Pulses are being sensed |
1000 0000 | GotSale data | New sales data available (i.e. Nozzle when down and pulses were detected while Motor ON) |
Digital Status Byte | Description | Function |
0000 0001 | Tag1 Data Available | A Tag was just read on RFID1 |
0000 0010 | LCD/KeyPad1 Tasked to do a cycle | This means it is in a process to collect an Odometer or PIN # |
0000 0100 | Keypad1 is Active | Keys are being pressed |
0000 1000 | LCD/KeyPad1 Has data to retrieved | Odo/Pin type data |
0001 0000 | Tag2 Data Available | A Tag was just read on RFID2 |
0010 0000 | LCD/KeyPad2 Tasked to do a cycle | This means it is in a process to collect an Odometer or PIN # |
0100 0000 | Keypad2 is Active | Keys are being pressed |
1000 0000 | LCD/KeyPad2 Has data to retrieved | Odo/Pin type data |
5. Payload Descriptor
This sends back the OpCode, the purpose is to tell the PC/MC what response is coming back so if there is something in the Payload, it can be identified as Tag or Pump data.