THEMA:

Hi! I'm Tom, developer of the "JLog". We do not know each other personally, but I think you know about Jlog, one of the first 3rd party devices supporting JETI telemetry.

Well.., JETI does not use a bus, the JETI-wire is a point-to-point connection, terminal/Rx to sensor, single sensor. If more than one sensor is to be connected then you need a "switchboard", an Expander.

Before "EX", with JETI v1, the role of the Expander was in fact that of a switchboard. Mainly.., except for some occasional hidden messages (alarms) passing the Expander without being explicitely connected to the message source (sensor). -- Only the Expander menu tried a bit to appear as concentrator by displaying line 2 of two sensors at once in one display.

Now, with EX, things have changed. Hidden EX messages forcing the Expander to act as a data concentrator all over the time. Virtually the JETI-wire converts its appearance to that of a bus, the line have to be available for every sensor behind an Expander around the clock.

And there is the crux.. Input speed (sensor side) and output speed (Rx side) of the Expander is equal..., but 4*1 <> 1
The Expander has to thin out the amount of data relative to the number of sensors currently located behind him.
Due to the size and time limits (9k6 only!) of a JETI packet and due to the corresponding size limit of a total of 29 bytes for an EX message -- at least a multi-sensor have to spread its EX-related data over more than one JETI packet.

Well..., I do not know what difference the "EX" in the name of an EX Expander makes compared to a version 1. But I know that an EX Expander is NOT EX-message-ID-sensitive handling packets received from sensors behind him.
Because sensors transmitting without prompting in a fix time scheme, and because transmissions from sensors are wether time- nor phase-synchronized of course, that leads to the problem that some packets will rarely to never go into re-transmission by the Expander. This is so because the Expander seems to simply repeat the last completely received packet from a sensor, round-robin over the four sensor interfaces.
Which can cause that some sensors never will bring all of its data (contained in more than one EX message) through the Expander to the Rx. The result is that corresponding EX data displays in the terminal (transmitter, Profibox) run on timeout.

That all is a function of the number of EX messages a particular sensor needs to bring all of its data out, and of the number of sensors behind an Expander.

Well... JETI cannot simply move to a bus protocol with an arbiter (busmaster) because they have to stay compatible with v1 devices out there which also may not have the ability of firmware upgrades by users.


Conclusion/suggestion:
The Expander E4 EX should at least operate ID-sensitive in handling of hidden EX messages, as a terminal does. Means, the Expander provides that all (ID-tagged) EX messages of a particular sensor will pass him by time. ...To do what the "EX" in his name seems to promise, to be an EX device.

The root of all evil is that the baudrate of the line Expander-Rx is identical to that of the sensor interfaces of the Expander. Besides the problem mentioned above that causes anyway rising latency proportional to the number of sensors used behind an Expander.

So why not simply to go on a higher baudrate between Rx and Expander? That could be controlled/implemented by a special hidden message or simply by probing, Expander's concentrator interface on auto-baud. Or even more simple by setup of the receiver, Expander in auto-baud.

The way the Expander is implemented currently, he is an obstructive anachronism in JETI EX.


If you like to proceed by further discussion find my email address in the imprint of the JLog home page.

Best regards. Tom

Hi Edgar!

This board is called "Comments to JETI" and my post was aimed to JETI "indirect directly".

So I'd suggest to discuss your timing considerations in an extra thread and in German.
I will open such a thread elsewhere under the title "Expander E4, Timing mit EX", okay?

Tom