PumpController Settings and the MID - an MID Reference document 5 Jan 2020

[NEAL SINGH]

 

PumpController Settings and the MID

• MID Reference document 2 [5 January 2020]

This gives some understanding of the timings used with the PumpController in the MID Mode. It is recommended that these are treated as the minimum values to use to get a fast and stable performance. On Site, conditions will be far from these “ideal conditions “of a lab environment, so consider this as a starting point to work from. Through this knowledge and understanding can be developed so that typical settings can be achieved that can be used for most if not all sites with an acceptable performance.

This was done with SM 2000 and SM 2008 Pumps and settings may need to change with other pump types and similarly documented.

Additional Information

While we investigate the MID system there will be additional Debug information that can be accessed. Here you can see how to access this data and the information it makes available.

[General]

;MID DSW2/#4 - If the Sw is On, then the feature is disable and the Flag must be put OFF.

FastTagRead = 0

There is a setting on the MID to AutoSend a Tag as soon as the next comm. arrives. There is a shortcoming that was not foreseen. This meant that the Serial Port had to be ready for a larger packet of data that than the typical Pump Status response. The advantage of a fixed response is that there is no additional wait for a timeout, once the expected packet arrives, that cycle can is done and the PumpController can move on. On a particular test, there was a 60% speed improvement. It is recommended not to use this feature.

; MID -  Displays the actual Pump Comms from the MID packet

MIDExtract_Debug = 1

2020/01/04|00:00:01:109|COM5|  DRV PUMP : AGW MPD -> 2:0 Resp Time:10 msec   (Extracted R:)  [4]  F1 20 B0 E1

Information: This is time at the MID that the Pump responded to the command issued. The Extracted data is the response that was gotten from the Pump.

; MID: Give the RF Signal Strenght for all Comms in the debug message

RSSI_Debug = 1

2020/01/04|00:00:01:000|COM5|  DRV PUMP : AGW MPD -> 2:0  Response : 9 mSec    <<< RSSI >>> : -34

Information: This is time at the MID that the Pump responded to the command issued.

RSSI stands for Received Signal Strength Indicator. It is an estimated measure of power level that the PC Adapter receiving from the MID. At larger distances, the signal gets weaker and the wireless data rates get slower, leading to a lower overall data throughput. This would mean using better antennae or more RF Power to avoid NACKS. The higher the RSSI value, the stronger the signal. When measured in negative numbers, the number that is closer to zero usually means better signal. As an example -50 is a pretty good signal, -75 - is fairly reasonable, and -100 is no signal at all.

Much documented experimentation can occur with this much transparency with will lead to a better understanding of how a site should be setup. Also be aware that the PowerLevel of the MIDs can be dynamically adjusted from the INI file and it has been speculated that a lower PowerLevel can also improved signal strength. The type of antenna, the Frequency, the PowerLevel and the distance to the MIDs all play a role in adjusting this RSSI value.

 

 

The Settings of the PumpController ini

These setting were use for cable and RF comms. At a general rule, the TaggingPollDelay should be around half of the PumpsPollDelay.

 

;Delay values

PumpsPollDelay = 20

TaggingPollDelay = 10

 

NB: the values used – where zero was used, it found for these pumps, additional delays were not necessary when there were two pumps being polled. On a single pump setup, there might be a need to have to include a delay (TotalsDelay – GetSale & TotalizerDelay Get Totalizer)

[SM 2000]

StatusReplyLength     = 4

ReadTimeout           = 20   <- Wait Time for the first byte.

TotalReadTimeout      = 50  <- Total Wait Time if no data appears. Keep a low as possible.

TotalsDelay           = 0

TotalizerDelay        = 0

SetPriceCommandDelay  = 0

TotalsCommandDelay    = 90     <- The Get Sales Command – required a longer Wait for the data

TotalizerCommandDelay = 50   <- The Get totalizer Command  – required a longer Wait for the data

GetTotalizer          = 1

.

.

.

Caution: Should you have multiple pump types on the same comm. port, it is important to understand that the first Pump to be configured will define the setting for the Serial port. So if you have different settings for another Pump type, these will be ignored as the Port is already configured. The rule here is to configure the suitable settings for the slowest pump type on that port and set all the Pumps to those settings so you don’t have to be concerned with which pump will be configured  first.

 

[MIDDual1]

ReadTimeout           = 0   <-  Not used but required

TotalReadTimeout      = 0 <-  Not used but required

; 0 - No Header/ 1 - MID Header/ 2- CC1310  / 3- CC1310 Channel determined "BlueWire Style"

MIDMODE                 = 3

NetworkID             = 2

;Dest; 1 -MID / 2- MC / 3 - Repeater

Destination           = 1

Jumps                 = 0

//Repeater ID = 1-3

Repeater1             = 0

Repeater2             = 0

Repeater3             = 0

Repeater4             = 0

OrginationID          = 0

;Power Level 0-15

 

PowelLevel               = 15

FreqChannel            = 2

PortSettings          = 115200,N,8,1 <-  Not used but required

 

 

MIDMode

 

0 – Cable Mode

• This would require much demonstration to understand the possibilities but it will be just documented and those that are more adventurous can explore further.

Baud: Use Pumps native settings.

Hardware: MID, N540-RS485; MUX; COMM Driver & Multi-pump

Tagging: SFTDual Tagging using Pumps native settings via MID or Comms Driver with Tag Controllers etc.

 

1 – MID Cable Mode

• This would only work with the MID technology

Baud: Use Pumps native settings

Hardware: N540-RS485/ MID with RS485 at 9600 / 115200 and ribbon cable.

Tagging: SFTDual / MIDDual Tagging.

 

2 – MID/CC1310

• MIDs with the CC1310 RF link.

Baud: All pumps at 115200

Hardware: N540-RS485/ USB CH340 or MID PcAdapter and MIDs on Pumps

Tagging: SFTDual / MIDDual Tagging.

 

3 – MID/CC1310 – BlueWire Style 1

This is identical to MIDDual =2 but the INI setting of the MIDDual device  where the FreqChannel is set i.e:  “FreqChannel          = 2“  - this setting is now ignored and the setting is taken from the Tag Reader BlueWire Channel configured in the Tech Config.  (NB: not Pump, but the Tag reader BW channel) (NB: The current setup that has been tested and validated is the Fixed Channel approach where all the MIDs are on the same Channel ( as in Engen Waverley, the multi-channel set up will be tested soon - this will confirm on a large scale the smooth working across several Frequencies)

 

 

 

Important: When using the Pump native baudrate, you would need to make ReadTimeout and the TotalReadTimeout larger as these are typically slower baudrates requiring more time.

The TotalReadTimeout should be as small as possible as this will impact the speed of the system should there be a faulty Pump or MIDs that is down.

 

CC1310 Firmware

V3.0  is being worked which add more data.

The RF Report: When the Host (PC side) CC1310 send a message to the MIDs CC1310, an Ack is sent to the PC. Should there be no Ack, the PC assumes a failed communication and send an RF report to indicating the RF conditions.

If there are too many such RF reports, there are conditions that are causing comms failures and other channels need to be explored.

 

More about the RF WatchDog.

Now, once the WatchDog fires off a Reset, there will be Start-up Message sent to the PumpController. These are indicators that there are major comms issues on that Channel.