Ticket search results

TCK: No payload timestamps NDATA/DDATA

i-campbell — Fri, 01 Jul 2022 22:00:40 -0000

If you run the example project against the current develop branch of the Sparkplug TCK https://github.com/eclipse/sparkplug/ , you get the following failing test: topics-ndata-timestamp: FAIL The NDATA MUST include a timestamp denoting the Date/Time the message was sent from the Edge Node.; payloads-ddata-timestamp: FAIL DDATA messages MUST include a payload timestamp that denotes the time at which the message was published.; topics-ddata-timestamp: FAIL The DDATA MUST include a timestamp denoting the Date/Time the message was sent from the Edge Node.; payloads-ndata-timestamp: FAIL NDATA messages MUST include a payload timestamp that denotes the time at which the message was published.; Suggest a call to FB_Payload.SetTimestamp( ) is missing

Replace WSTRINGs with new SP18 UTF8 STRINGs

i-campbell — Fri, 10 Jun 2022 15:40:13 -0000

Currently we USE WSTRINGs throughout and convert to/from UTF8 for sending and receiving. This should be changed to use the new SP18 UTF8 STRINGs as described here: https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_utf8_encoding.html Note that we have a Global Constant SUPPORTED_STRING_LENGTHS : DINT := 512; That could hold 512 WCHARS, and takes 1026 Bytes of storage per string. It can hold 512 2-Byte or 256 4-byte Unicode characters. If we keep this value for UTF8 strings, each string would be 513 Bytes, and can hold 512 1-Byte or 85 6-Byte Unicode characters. This improvement would halve the storage size for strings, and make converting payloads faster, and also things like string comparison and manipulation.

Payload Decode: Robustness / BigEndian PLCs

i-campbell — Fri, 06 May 2022 20:20:06 -0000

Currently it is assumed that the payload being decoded is not corrupt. Also it assumes the Byte Order of the PLC is Intel (Little-endian). Note the Byte Order of the Payload must be Little-endian. Perhaps use a MemUtils.ByteBuffer to accomplish both goals.

FB_Payload, Pool Management: Used FB_PayloadColumns are not reused

i-campbell — Mon, 24 Jan 2022 09:44:41 -0000

ClaimNextFreeColumn never reuses columns and always generates a new column from memory. Luckily, DataSets are not yet implemented, so this Method is not yet called.

Migrate TransferAllElements() out of SPStack into colist

i-campbell — Sat, 22 Jan 2022 07:52:15 -0000

The function TransferAllElements is List functionality so it should be transfered to colist (co🔗e)

Edge, Stack, Example: Tidy up some warnings

i-campbell — Fri, 01 Apr 2022 22:21:54 -0000

When you compile the example project you get a few warnings. These should be fixed. Tip: URL_ENCODE_WSTRING2.udiSizeOut is in Bytes

Device: Some Device Messages are skipped, noticably DBIRTH

i-campbell — Sat, 30 Oct 2021 17:45:03 -0000

When an Edge starts up, it publishes: NBIRTH/E MISSING: DBIRTH/E/D1 DBIRTH/E/D2 DBIRTH/E/D3 find the cause of the missing device messages.

Library Category: add Application category so library can be selected without "Display advanced libraries"

i-campbell — Sun, 13 Jun 2021 14:46:03 -0000

By Adding an additional library category "Application", the library can be found also when the "Display advanced libraries" button is not pressed. The category can be found in C:\Program Files\CODESYS 3.5.16.40\CODESYS\Templates\Library_Template\LibraryCategoryBase.libcat.xml

Edge, Host: Support Templates

i-campbell — Sun, 21 Nov 2021 00:48:06 -0000

Templates allow you to define a specific structure for data, and then implement several instances. Partly the advantage is that, if you transmit "names" rather than aliases, you translate the instance name once, and then just the member names. Additionally, there are some Object Oriented advantages, for example making faceplates that require a particular template as input. so: 1. [x] FB_Metric should be able to have one FB_Template... which needs to be able to have several FB_Metric :D 2. [x] FB_Edge needs to be able to xBIRTH 3. [ ] FB_Edge needs to be able to send xDATA 4. [ ] FB_Edge needs to process xCMDs 5. [ ] FB_Host needs to be able to process xBIRTH 6. [ ] FB_Host needs to be able to process xDATA 7. [ ] FB_Host needs to send xCMDs 8. [ ] FB_Host needs to process xDEATH 9. [ ] The user will want to be able to efficiently link these to DUTs (both in the Edge and in the Host). That might be a 3.0.0.0 feature, but thought should be put into how this might be realised.

PrimaryHost: Itterator

i-campbell — Sat, 05 Nov 2022 21:20:03 -0000

The host needs to scan for items which need published (xCMDs). This itterator may later be expanded to include metrics, properties and so forth. xCMD crawler: 1. loop all Groups 2. loop all Edges 3. loop all Devices //Will Cycle through the Groups.Edges.devices. 1st it will find the first edge of the first group. Then it will either go deeper (G1/E1/D1) or down if there are no devices (either G1/E2, or G2/E1) // Bool: OnlyOnline := TRUE will skip offline things // Bool: EndOfList := TRUE indicates the end of list has been reached FB_DeeperAndDown() Continuously call FB_DeeperAndDown() until EOL or you find a DeviceOrEdge which wants to publish => then publish it. FB_DeeperAndDown( Groups := _Groups , OnlyOnline := TRUE , itfXcmdSender => itfXcmdSender , EndOfList => EOL ); IF (NOT EOL) AND itfXcmdSender <> 0 THEN IF itfXcmdSender.getXcmd(itfPayload => xcmdPayload ) THEN Publish(xcmdPayload); Published := TRUE; THEN END_IF;

Edge: SFC itterator

hermsen — Fri, 30 Apr 2021 13:34:43 -0000

It is a requirement to have things published in order FB_Edge will receive an itterator which in a single scan, it will itterate until it finds an (Edge or Device) which wants to publish. The state machine then goes to PUBLISH and waits until the publisher is done. It then returns to the ITTERATION state to complete (does not restart) if the itteration completes without finding anyone who wants to publish, it ends the state and restarts the ittetration. The "not restarting the itterator" may be crucial for not favouring a particularly busy device over others. Effectively the itterator is normally a "looper".

Edge / Device BUG SeqNums

hermsen — Fri, 30 Apr 2021 13:34:43 -0000

Requires -> [#128] new implementation of FB_EdgeMQTT client Requires -> [#129] SFC itterator

PrimaryHost, Edge: QoS

i-campbell — Sat, 05 Nov 2022 21:20:03 -0000

The following **exact** QoS should be adhered to: Message | Publisher | Subscriber ---------- | ---------- | ------ NBIRTH | QoS 0 | QoS 0 DBIRTH | QoS 0 | QoS 0 NDATA | QoS 0 | QoS 0 DDATA | QoS 0 | QoS 0 NCMD | QoS 0 | QoS 0 DCMD | QoS 0 | QoS 0 DDEATH | QoS 0 | QoS 0 NDEATH | QoS 1 | QoS 1 STATE | QoS 1 | QoS 1

PrimaryHost: Investigate suitability of FBFactory for dynamic structure

i-campbell — Sat, 05 Nov 2022 21:20:03 -0000

Investigate if FBFactory will be useful for creating a dynamic metric tree: https://help.codesys.com/webapp/fb_factory;product=LibDevSummary;version=3.5.15.0

FB_RemoteEdge

hermsen — Sun, 25 Jul 2021 12:46:25 -0000

FB_RemoteEdge parses and allocates Edges (nodes)

FB_RemoteDevice

hermsen — Sun, 25 Jul 2021 12:46:03 -0000

FB_RemoteDevice scans and allocates detected devices

FB_GroupID

hermsen — Mon, 22 Feb 2021 20:23:03 -0000

FB_GroupID is allocated through NBIRTHs and holds a list of Birthed Edge Nodes

PrimaryHost: Dispose of unwanted objects

i-campbell — Sat, 08 May 2021 13:13:14 -0000

So the Primary Host starts with a collection of blank GroupIDs, RemoteEdges, RemoteDevices, and Metrics. on xBirth, it will assign these values. It should be possible to dispose of these objects if they are no longer required. GroupID => Explicitly by the end user RemoteEdge => Explicitly by the end user RemoteDevice => Explicitly by the end user Metric => On xBIRTH, when the metric is no longer declared Disposing a GroupID will recursively dispose of all children and so on.

Metrics: Read only

i-campbell — Sun, 31 Oct 2021 13:58:12 -0000

Provide a way for a metric to be read only. This will be a Function Block Property of FB_Metric with an enum called Access, of Type AccessMode: - ReadWrite (default) - ReadOnly If a xCMD is received, and that metric is ReadOnly, the value is not written. The Edge will however send a new xDATA asserting the old value, so hosts will not be able to assume the write was successful. SparkplugB spec does not define a way to communicate that a metric is read only, so our library has left this up to the user application. For example, you might add a Boolean Sparkplug property 'ReadOnly'. Note, FB_Edge and FB_Device do not have a similar property. In future, it will be possible to set the AccesMode also to 'inherited'. This would make it easy to set all metrics of a device to read only.

FB_PrimaryHost: Construct "Dynamic" Structure of Edge Nodes

i-campbell — Sat, 05 Nov 2022 21:20:03 -0000

Using these methods, construct a tree of groups / edges / devices / Metrics under a PrimaryHost: onNBIRTH() onNDEATH() onDBIRTH() onDDEATH() onNDATA() onDDATA() onNCMD() onDCMD() onSTATE() it should use the following FB's: FB_GroupID FB_RemoteEdge FB_RemoteDevice FB_Metric

AWS IoT Core Support

ferraraf — Fri, 05 Feb 2021 18:24:34 -0000

Can we please get this AWS compatible with the AWS IOT Core Client library? Kind regards

EoN, Device, Host, Payload: Optionally and by default, send metrics using Aliases

i-campbell — Fri, 01 Apr 2022 19:09:30 -0000

It is more data- and processing- efficient to use aliases for metrics than to use the full metric name. A setting should be available to enable aliases. 1. send xBIRTH will send both the name and alias. 2. send xDATA will send only the alias. 3. receive xCMD should match first on Alias, but if no Alias is in the metric then it should match on Name. * [x] Edge and Device Alias xBIRTH and XDATA mechanism are implemented. * [x] Edge and Device decode xCMD alias implemented, * [x] CODESYS Host decodes aliases in xBIRTH and xDATA * [x] CODESYS Host sends alias xCMD Release note: For an Edge, the input to the function UseAliases controls whether aliases are generated and used for each metric in the edge and its child devices. For a Host, the use of aliases is entirely up to the Edge and its Devices - if the edge births with aliases, FB_Host will send NCMDs with aliases. Similarly if a device is birthed with aliases, FB_Host will send DCMDs with aliases.

Paylaod: refactor

i-campbell — Sat, 15 May 2021 23:45:24 -0000

At the moment, there is a relatively complex structure for adding metrics and its subobjects to a Device, and then later to a payload. You have to add all of the pools of objects, and pass these between the FB's. Some issues: 1. The calls for each Object are quite a lot of lines of code, with up to 10 different pools needed. 2. Some people might accidentally add a metric to two different owners. So the proposal is for each object to have an interface to register its children. The children then use this interface as an input, and register themselves. Note that a Metric may have two owners, a Device and a Payload. Payload Implements IPaylaod Metric.itfOwner := Payload; Or myMetric : Metric := (itfOwner := Paylaod); or myMetric(itfOwner := Payload); Also take into consideration that the SCADA node might actually want the freedom of Pool Objects, ie it might still want MetricsPool. This might mean making two seperate calls available.

Implement trigger for a DDEATH message as input FB_Device

hermsen — Sat, 19 Dec 2020 01:23:57 -0000

An input on the Device POU should trigger sending a DDEATH certificate for this device. This input serves to accommodate this as the customer can then build a watchdog in their application to monitor the physical device. If the physical device is offline and the watchdogs triggers, this will be notified to the primary SCADA. FB_Device input : Device_Healthy, must be TRUE, if this signal becomes FALSE the DDEATH certificate will be issue if the connectionstate is online. During this phase the device will not send any data again. After the Device_Healthy has been set to TRUE, the device can resume it's normal course of functioning again (plugged, DBIRTH, DDATA etc). This mechanisms requires at least two states: DDEATH and HEALTH_RESTORE state DDEATH publishes the DDEATH certificate and after this the device moves to HEALTH_RESTORE state where the device idles and waits until the device health status returns to normal. After this the Device returns to the INIT state and resumes PLUGGED/ONLINE Note that the monitoring and sending of the input is only valid during device online sessionstate. If the EON session turns to offline during DDEATH period, the device will stay in HEALTH_RESTORE until the device is again healthy. If so the device goes to INIT and resumes plugged/ OFFLINE

Versions: Downgrade to 3.5.14.0

i-campbell — Sat, 06 Feb 2021 16:37:40 -0000

Downgrade library, compiler version, project, device to 3.5.14.0. This is the minimum system requirement for the MQTT Client SL. Moving to a lower version will allow more runtime systems to use this code.