According to the Reseller, the SmarToo programming must adapt to PNPSCADA, or PNP must adapt to the SmarToo programming.
He is sitting in the middle.

In general PNPSCADA adapts to whatever you gave the SmarToo to do through setting it up for a specific scenario, for instance, measuring analogs and logging it, or logging pulses and feeding that to pulse meters, or reading Elster IrDA meters directly, or switching contactors on and off via digital outputs. Additionally, you can talk over the modem to a meter or device you connected to it via the serial port.
The IrDA meter that is connected to the SmarToo maps onto the SmarToo datalogger RTU device in PNPSCADA itself (there can be only one). That is why it is a meter. If you're not doing this, physically, be sure to disable the checkboxes in the datalogger's Advanced Meter Settings.
If you are reading Pulse Meters via the SmarToo, add the Pulse meters and connect them to the correct pulse output from the SmarToo datalogger RTU entity in PNPSCADA.
If you are switching any digital outputs on the SmarToo, add Contactor entities on the relevant ditigal output exported interfaces from the SmarToo datalogger RTU entity in PNPSCADA.
If you are reading e.g. Analog values like temperature, it maps into the Instrumentation Profile on the SmarToo datalogger RTU entity itself. There should be only one record like that.
All datalogging commands (!98); must be on a minute per hour, or some such regimented timer. Not the general timers, since they are not 'on-the-hour', and therefore not exact enough for metering purposes, e.g. not on end-of-month.
Every data logged command is distinct, and must have the date and time (,) in it, and it must also have an end of line (). Furthermore, if you are logging more than one line, there must be something at the start of the line that will identify it to PNPSCADA, e.g. a literal string, like (L1,).

So, basically, in this case, the SmarToo was outfitted with 3 expansion modules, each of which is measuring 8 pulse inputs.
The basic problem was that the logging string was too big to all fit into one command string. So we ended up with using macros:
We ended up with a setup as follows:
Set up event one to run every 30 minutes, based on midnight:
!78 1 30
Set up event one to run 3 macros, namely macro 8, 9 and 10:
!79 1 !46 8 !46 9 !46 10
Set up the three macros to log the 8 pulse values from expansion 1, 2 and 3:
!45 8 !98 "L1,,,,,,,,,,"
!45 9 !98 "L2,,,,,,,,,,"
!45 10 !98 "L3,,,,,,,,,,"
Please do not try to build 1 line from 3 commands, because it is not always clear in what sequence they will actually be executed and logged.
For the above, switch off all checkboxes on the Advanced Meter Settings of the SmarToo logger itself, and enable to Profile checkbox for the Pulse Meter entities that is connected to it.

So, to come back to the original point, there are some basic requirements that must be adhered to when programming the SmarToo for PNPSCADA, and most of them are simply logical if you think about it. For instance,

1. Use the correct timers for logging data, the ones that run at the exact right times on or after the hour.
   
2. one line must equal one record for the datalogs (every log command must end with a line break)
   
3. every line logged should contain the date and time as fields
   
4. if more than one line is logged, it should be preceded by a literal identifier, e.g. L1, L2, etc. so that PNPSCADA can know them apart.
   

PNPSCADA will try to adapt where it can, but in some instances, a SmarToo can be programmed in a way not compatible with PNPSCADA. Usually this would also mean the information is nonsense, or in a difficult to understand format, e.g. if you log everything on one line, or build one line out of many macros, or if you don't have a linebreak or date and time in all logged entries.