Workbook – Smila

In the startup sequence of the DLL, the hostname, the DLL version, and the firmware version are recorded. Additionally, in the current versions of the DLL, the CCID of the SIM card is also captured, which is necessary for analyses in the KPN portal. This entry is always generated at the start of the DLL and thus also at the start of the app, as the app initiates the DLL.

End sequence of the DLL

When the app is closed, the DLL is also closed. This sequence starts with the term DLL_PROCESS_DETACH in the log file. All components are then closed. However, if the device is restarted or shut down via the app, no entries are created in the log file. If this entry is found in the log file, the app has been closed.

Logging reduction

To prevent the same information from appearing repeatedly in the log file, the GetStatus and GetSingleProcessing queries are only entered shortly after the DLL is started if there has been a change since the last entry for this function. This is necessary because the app queries these entries every 5 seconds, which quickly makes the log file confusing and difficult to analyze.

Idle mode

In idle mode between individual TTs, the jdmDcSetTime and jdmDcSetBatteryMode functions are called by the app at regular intervals. The ProcessData entry is the feedback from DControl to jdmDcSetBatteryMode. These entries must be called alternately by the app in the log file during idle mode. If only one entry appears, the respective thread in the app is stuck. It is then also very likely that other functions of the app are affected. Consequently, the missing entry can be used to determine the time at which the error occurred. To fix the error, the app must be restarted. However, the processing list should be checked beforehand to avoid causing subsequent errors.

jdmDcGetStatus function

The jdmDcGetStatus function outputs the current status of the DControl (first function call in the screenshot). The DLL then packages the important information for the app into a simpler structure and passes it on to the app (second function call).

The following information is usually required for analysis in the first function call:

PPE: Error registers EC1-EC6 for the last bag dispensed. An error register consists of 32 bits and is output in hexadecimal format. The error registers are described in the corresponding ErrorCode.h file. The registers are reset at the beginning of each output.LBC:

This field contains the last barcode found. This entry is particularly important for analysis in the case of a wrong barcode.

EC1-EC6: This error register collects all errors that have occurred since the last reset of the DControl. These are the same error codes as under PPE.

Im zweiten Funktionsaufruf sind folgende Infos für die Analyse interessant: / The following information is relevant for analysis in the second function call:

• BPOS: The current motor step counters are stored in this register. Please note: the values are in hexadecimal! A jdmDcGetStatus is called for each image. The difference between two jdmDcGetStatus results in the number of motor steps that were performed between the two images.

The counters are assigned to the motors/rollers as follows:

Input rollers left, output rollers left, input rollers right, output rollers right.

• RLSA: Current value of the RLS in hexadecimal. Values are to be understood as follows: Input RLS left, output RLS left, input RLS right, output RLS right

• RLSC: The threshold value for the RLS of the sub-steps that must be exceeded in order for the RLS to be considered triggered.

• RLSPH1: Displays the output RLS value that was present at the time of the premature triggering in PH1.

• SMSTPS: Displays the steps registered in the security module for the respective mechanism.

• bOperationPending: Indicates whether the mechanism is processing a command such as bag transport.

• ucPPIndexLeft, ucPPIndexRight: Line number of the respective processing list that is currently being processed.

• ucCurrentRLS: Indicates which reflex light barriers are currently detecting a bag. When a bag is detected, the respective bit in the register is set to 1. The value is output as a decimal number.

Bit0: Input RLS left side Value=1

Bit1: Output RLS left side Value=2

Bit2: Input RLS right side Value=4

Bit3: Output RLS right side Value=8

ProcessingList

11. 13. 12. 10. 9. 8. 7. 6. 5. 3. 4. 2. 1.

The jdmDcGetSingleProcessingList function outputs the stored processing list for the selected mechanism side. The following additional information is also output:

Time: The time is output in Unix timestamp format. The first number is the world time and the second number is the local time as a Unix timestamp.

ucMechanicNr: Specifies the mechanical side for which the displayed processing list applies. The left mechanical side is represented by a 0 and the right mechanical side by a 1.

ucCurrentIndex: Displays the line in the processing list that is currently being processed.

ucCurrentWorkingFlag: Indicates whether the DControl is processing the ProcessingList.

PC: Displays the local time of the computer.

Batt: Displays the last battery capacity reading.

PPE: Error registers EC1-EC6 for the last bag output

The processing list is divided into 13 columns, of which only the first 9 are actually present in the DControl. Columns 10-13 are created by the DLL from the others and are used for easier analysis. Each line represents the information about a bag. The respective columns contain the following information.

1. State: Current state of the bag in the bag dispenser in hexadecimal notation. The individual states are described in DControlDefs.h in the DControl-FW folder under \\Dok_serv\2-p\JDM-Software\Software_Dispenser\DControl_Firmware.

2. Checksum

3. cBarc: The barcode of the bag to be dispensed. This is compared with the barcode that is read.

4. TT: The time at which the bag is to be dispensed. This is stored as a Unix timestamp.

5. T1TTW: The time until which the bag may still be dispensed.

6. T2TTDrop: The time at which the missed bag is to be discarded.

7. TReq: The time at which the bag was requested by the patient.

8. TWithdr: The time at which the requested bag was removed from the dispensing chute.

9. TDisc: The time at which the missing bag was discarded.

10. The current state in text form

11. The TT in plain text.

12. The T1TTW in plain text.

13. The T2TTDrop in plain text.

All times in the PL are given in the local time of the system.

Pouch distribution procedure

The states that must be passed through for successful pouch dispensing are as follows:

WaitingForTakingTime (0x01): DControl waits until the time for dispensing is reached.

Advancing (0x03): Pouch is advanced, and the barcode is searched for. The pouch is then moved to the cutting position.

InCuttingPosition (0x04): The pouch is cut.

PouchCuttedAndOnHold (0x05): The pouch is cut.

PouchOnHoldWithPCSound (0x06): The user is informed via the loudspeaker that a pouch is about to be dispensed.

PouchDispening (0x08): User has requested pouch dispensing.

WaitForSecurityModule (0x09): Pouch is in the dispensing chute.

PouchDispensedWithoutFollowingPouch (0x0b): Pouch has been removed from the dispensing chute.

PouchOk (0x14): Pouch dispensing complete.

If several pouches are due at the same TT, only the last pouch will go through the above states. The previous pouches differ only in points 5 and 8. Instead of point 4 in point 5, the system switches directly to point 6, and instead of state 0x0b, it switches to state 0x0a PouchDispensed. Processing the next pouch is then started.

Each time the state changes, a message MSG_STATE_CHANGED with the new state as a parameter is sent to the app. The entry in the log file looks like this:

Error during pouch dispensing

WrongBarcode

If the barcode read does not match the one stored in the ProcessingList, the state changes from 0x03 Advancing to 0x0e WrongBarcodeWaitingForDrop. To understand how the barcodes do not match, the LBC can be compared with the barcode in the ProcessingList in jdmDcGetStatus. When T2TTDrop is reached, the status changes to WrongBarcodeSoDropped. In the event of this error, the roll should be reinserted.

BarcodeNotFound

If no barcode is found in the search area during the search process, the state changes from 0x03 Advancing to 0x0d BarcodeNotFound. To find the reason for the error, the images in DScan must be viewed and appropriate action taken. It may be sufficient that the bag was not pulled far enough forward at the start of transport to cause this error. This can happen, for example, if the roll is pulled out of the device manually and then no insertion process is carried out, but the roll is only placed on the rollers. In the worst case, the roll must be reinserted.

Missing Processing List

At each output point of a bag, a message and a processing list should be present in the log for each state change. However, if only the messages are still present in the log and there is no processing list, it may be that the app is querying the processing list of the other side. Since nothing changes in this list, no entries are created in the log. However, since updating the processing list after a PouchOk is important for sending the notification to the cloud, the corresponding entry for the successful output is missing in the cloud.

Pouch in output tray

If the pouch has been requested and is not removed, the status changes to PouchNotTakenWaitingForFreeRLS (0x12). If a pouch is detected by the output light barrier, no further pouches are dispensed because the output chute is not free.

Writing a processing list

The app may only write a processing list to the DControl if CurrentWorkingFlag=0. To ensure that the DControl interrupts the processing list, the app sends a stop request for the corresponding mechanical page to the DControl. Only when CurrentWorkingFlag has been set to 0 by the DControl may the app send a new processing list to the DControl. The CurrentWorkingFlag is then set to 1 again by the DControl.

In the following example, a bag has been successfully issued and is therefore removed from the processing list.

Insert a roll

During the loading process, the first step is to open the lid (MSG_LID_OPENED_OR_CLOSED) and wait for the RLS to detect a pouch. Once a pouch is detected by the RLS, the loading process begins. This is forwarded to the app with the message MSG_LOADING_ROLL_STARTED. Once a barcode has been found, an MSG_LOADING_ROLL_COMPLETED_WITH_BARC message is sent. The barcode found is read by the app using the PouchID parameter of the jdmDcGetDataFromLeadingPouch2 function. If the barcode found is in the patient's barcode list, the app then writes a PL, with the barcode in first place. However, it is also possible that the barcode found is assigned to another patient. In this case, the app will not write a PL.

If no barcode could be found, an MSG_LOADING_ROLL_FAILED is sent and the roll is ejected. The reason must then be sought based on the images and error codes. One reason could be that the bag has started to be pulled in, but the bag has not been taken. Another possibility would be that the wrong blister type is selected in DControl. However, this would be an exception, as the blister type does not change during operation.

Eject a roll

During ejection, the first step is to open the cover (MSG_LID_OPENED_OR_CLOSED) and call the ManualServiceCommand function. This is passed the corresponding mechanical side, the command, and a parameter. All possible commands are described in DControlDLLDefs.h. To eject the roll, the command 1 FeedMotors is passed with the parameter -560. This transports the roll backwards by 560 steps. The parameter IDX returns the CurrentIndexLeft, CurrentIndexRight, CurrentWorkingFlagLeft, and CurrentWorkingRight. After the ManualsServiceCommand was successful, the app writes an empty processing list to the corresponding mechanical page.

Lid Open

If the function jdmDcOpenLid is in the log file, the app has requested that the lid be opened and DControl opens the lock via the actuator. DControl then detects that the status of the switch on the lid has changed and sends a message to the app. The current status is stored in lParam. If the parameter is 1, the lid is open, and if it is 0, the lid is closed.

If the lid is opened using the key, only the message entry will appear in the log file. This should not normally happen, as it can lead to incorrect operation. An example of this would be if a roll is removed without the app's knowledge.

Removing the drawer

When the drawer is removed from the dispenser, the DControl detects this via a switch and sends an MSG_DRAWER_OPENED_OR_CLOSED message to the app. The status is displayed in lParam. If the parameter is 1, the drawer has been removed (approx. 1 cm is sufficient to trigger this) and if it is 0, the drawer has been pushed in.

Fingerprint

To log in to the AUM, either a manual login or a fingerprint login can be performed. To do this, the app transfers a template list of the trained fingerprints to the DLL. This then initializes the fingerprint reader, and the template of the placed fingerprint is captured. This is then compared with those in the transferred list. If a match is found, the number of the template in the list is transferred to the app. This is recorded in the log file as “Finger identified.” If the template does not match any in the list, “Finger not identified” is entered in the log file. If this was due to the positioning of the finger (too high/low/etc.), this is also noted in the log file.

However, we have received reports that logging in via the fingerprint reader did not work. But in our log file, the fingerprint was recorded as recognized. If you search the app's log file for the time when the fingerprint was identified, you will also find the user ID assigned to the fingerprint. Consequently, something went wrong when logging into the app and needs to be investigated further there. This means that a fingerprint can be recognized correctly, but the login can still fail.

Hibernate/Batterymode

When the dispenser is running on mains power, jdmDcSetBatteryMode is called with the parameter ucOnOff=0. This signals to DControl that battery mode should be deactivated. In the parameter of the message MSG_GOING_DOWN_IN_X_SEC, DControl informs the app whether battery mode is deactivated or active. If the value is 02000000, battery mode is canceled. If the value is 010000XX, battery mode is active and the system will go into hibernate mode in XX seconds. The value XX is in hexadecimal and must be converted to the decimal system.

If the mains voltage fails, the system automatically switches to battery power. The app detects this with a slight delay and communicates this via the jdmDcSetBatteryMode function and the parameter ucOnOff=1. This then sends a message MSG_GOING_DOWN_IN_X_SEC with the parameter 01000041. This means that the system switches to battery mode and goes into hibernation in 65 seconds. After 65 seconds, DControl informs the app via the message MSG_HIBERNATE_NOW that the system is now going into hibernation mode. Since no logging takes place in hibernation, there will be a time gap in the log file (framed in red in the example). When the system is woken up, logging continues. If it is determined that the mains voltage is available again, battery mode is deactivated as described above.

Furthermore, when logging the messages, the last measured battery capacity and input voltage are also stored.

Anydesk

Smila Screen:

Here you can see the device screen. This is what the patient can see as well!

Data Screen:

Here you can see the paths from your computer on the left-hand side and the paths from the Smila device on the right-hand side.

Important Paths:

Logfile: C:\JDM\Protokolle\DControlDLL

Pictures: C:\JDM\DScan\Anonym

Restart of the app:

You need to connect to the device (Smila-serialnumber@smila) and click the “Windows” Button on your keyboard to see the screen (see screenshot).
You need to close the Updater on the bottom right hand side (Right click and click “close”).
You need to close the app (Right click and click “close)
You need to check the Windows Task Manager if there is a Wpfpad.exe running. To open the Windows Task Manager right click on the Windows symbol on the bottom left-hand side and click on “Task Manager”. If an instance is running, please mark it and click on “End task”.
To start the App you need to open the “WpfPadUpdater.exe”, which is located on the Desktop.
You have made it! If the app does not open, please repeat the steps!

Edit audio volume:

You need to connect to the device (Smila-serialnumber@smila) and click the “Windows” Button on your keyboard to see the screen (see screenshot).
Click in the the bottom right-hand side om the speaker icon to edit the volume. The standard is 80%!

EscalationProcListWrittenWithT1Reached

EscalationProcListWrittenWithT1Reached pops up when a Taking Time was written with and already reached T1 time. This can happen in four different ways:

An error with an outdated was not removed but the roll was already inserted on the second compartment or next roll started, this pops up every time something was changed/written at the Processing List until the outdated Taking Time has been removed:

In this case you need to delete the outdated Processing List.

To log in you need the password all of you have received.

Enter the “Blue Support Screen”. In the top left hand side there is a field called Roll ID for the left roll compartment M0. In the top right hand side there is a field called Roll ID for the right roll compartment M1.

To delete the roll you need to mark the roll id, delete it and click on “save”. After that the roll will be deleted and you can click on “GO BACK” on the top right-hand side. Please check the logfile afterwards!

Patient missed a multiple Taking Time. After the first pouch was dropped it will be removed from the Processing List and the second Taking Time was written to the upcoming one. As we the Processing List was changed/written the message will pop up because the T1 time was already reached.
Device was switched off and roll was not ejected. When the device will be switched on again there will be outdated pouches which will be dropped. There will be an alert for every pouch!
The device ran out of battery and the roll was not ejected. When the device will be switched on again there will be outdated pouches which will be dropped. There will be an alert for every pouch!

Escalation Pouch List TT Reversed

This message comes up if a barcode is not ascending. Every time the processing list gets changed it will be sent.

In this example the barcode 00893275400002 was processed and got deleted after it was dispensed. A new pouch was pushed in the Processing List from the bottom (FirstInFirstOut). The new pouch has a not ascending barcode 00893155100022. In most cases the pouch was reproduced as there has been a mistake (material error) or the patient had a change in his/ her medication plan.

In those cases, you only need to check why the alert was sent and if it will be dispensed to the Taking Time.

Device update:

If you need to update a device, you need to go to “System Management” -> “Device Manager” in the cloud.

As first point you need to update the updater. Click on “Update Updater” and choose the needed version.

To update the updater is quick so after approx. one minute you can start with the device update. To start the device update, click “Schedule Update”.

To start the update immediately please remove the “Update time” by clicking on the “x”.

Please check on the device page if the device was updated. You can also connect to the device to check the version in the AUM.

Cutter calibration error:

This error comes up if something with the cutter is not working. In the most cases the pouch was cut open and the cutter ran against a pill. If this error occurred the device is blocked -> rollers are not working.

How to find:

ESCALATION_CUTTER_CALIBRATION_FAILED was received or found in the DLL Log.
PPE has 00200800 or similar in the first part (Please check “Error.h” file).

How to fix:

Open DTest
Reset of DControll (Soft- or Hardreset)
Clear PPE in DTest
Click Recal Cutter
Refresh PPE
Check logfile
PPE EC1: empty = resolved!
Error still in PPE? -> Move cutter forward for 3000 steps:
Refresh PPE.
Error still in PPE? -> Hand it to JDM Support

Can not read status:

This alert comes up if the connection between DControll & Pc is interrupted.

How to find:

ESCALATION_ERROR_CANNOT_READ_STATUS was received or found in the DLL Log.

GetStatus is missing in Log:

How to fix:

Open DTest
Reset of DControll (Soft- or Hardreset)

If this didn’t help, try a restart of the device
If the restart didn’t help, hand it to JDM Support

Requests:

Insert not working:

check logs if there are errors. If there are errors analyze them with “Error.h”
check anonymized pictures if there are abnormalities (Old pouch, pouch sprained/ trwisted)
ask if barcode looks fine (sometimes the print is damaged)

Offline:

If a device is displayed offline in the cloud, this does not mean that it is also unavailable via AnyDesk. Please try to connect to it.
If you can connect restart the app see here:
If not, a restart is needed. If the nurse is able to login to the AUM the lid needs to be opened with “remove missed medication” button. If the lid is open the nurse can press the Hardware Button for 5 seconds. Device should restart. After the pc was shut down the nurse can use the main switch.
If the nurse is not able to log in the lid need to be opened with a key and the switch need to be used.

Please try to avoid to reboot the device via the main switch as it is bad for the device.