One-Wire and CRC

[Eric]

Hi team,

One-wire components are very sensitive to transmission errors caused by cabling capacity and reflections, specially if you use long cables and multiple one-wire sensors. In the one-wire protocol this is handled by a CRC errorchecking. In case of errors, erronious data is rejected and a retransmission is requested.
I noticed that there is a CRC checkbox in the external properties of the one-wire component.
If this box is checked, I suppose that this will activate this CRC errorchecking between the master and the slave devices.
Can you confirm that this is indeed the case and that we can rely on the correct CRC errorhandling of Flowcode to trust the correct and errorfree communication between master and slaves ?
This is important to know if we will use one-wire temperature sensors for example heating control applications.
Is this function realy implemented?

Best regards,

Eric

[Benj]

Hello Eric

The CRC check function is correct and does work on the one wire component.

[Eric]

Thanks Ben, nice to hear.
I have another question on one-wire.
Suppose you have 5 temperature sensors connected via 1 cable to the master.
To address these sensors, the master must know the romcodes of all devices.
Only then the master can give his commands to 1 specific sensor.
The master detects these romcodes by issuing the commands "busreset, scanbus and getdevicecount".
After this combination of commands, Flowcode knows the romcodes of each sensor and can address sensor 1 or sensor 2 etc.
This all works fine in flowcode 4.1: if there are 5 temperature sensors DS18S20 on 1 cable, every sensor is detected and given a certain devicenumber.

However, 2 things are unclear to me:

1) The attribution of these devicenumbers does not seems to be determined by the location of the sensors on the cable. The 4th sensor for exemple can receive devicenumber 1 etc.
2) The attribution does not seems to be determined by the serial number of the sensor neighter. The lowest serialnumber doesn't get the lowest devicenumber.

So there must be another rule by which Flowcode attributes the devicenumbers.
My question now is: can we be sure that Flowcode attributes always the same sensor to the same devicenumber, even after a shutdown of the controller? This is important to know because if I construct eg a heating controller, I must be sure that eg the furnace sensor will always be attributed the same devicenumber between reboots of the controller.
Otherwise I am in deep trouble.

Best regards,

Eric

[Benj]

Hello

The one wire protocol is fairly random and if multiple devices try to acknowledge a command then they will both back off and wait and then try again. So it is the first device to back off and then get in on its own before any other devices. This is not Flowcode based but is critical to the workings of 1 wire devices.

If you must guarentee the numbers assigned to particular devices then you can either power then up one at a time. as you run the initialisation or you can base the IDs on the ROMcodes rather then the generated ID that is returned.

[Eric]

Ok.
But in that case I think there should be added an essential function in the list of one-wire parameters: the function "match rom".
It has as input the 64 bits romID of the one-wire device and returns with the addressed device selected.
Any chance to add this function?

Best regards,

Eric

[Benj]

Hello Eric

Ill add it to the list and see if I can find some time today to get it rattled off.

[Eric]

Much appreciated!

[Benj]

Hello Eric

There is already this routine as part of the 1wire component.

oo_get_IDByte

This returns a byte from the ROM code.

so if you did this you can grab the contents of the ROM code attached to say device 0.

byte0 = oo_get_IDByte(0, 0)
byte1 = oo_get_IDByte(0, 1)
byte2 = oo_get_IDByte(0, 2)
byte3 = oo_get_IDByte(0, 3)
byte4 = oo_get_IDByte(0, 4)
byte5 = oo_get_IDByte(0, 5)
byte6 = oo_get_IDByte(0, 6)
byte7 = oo_get_IDByte(0, 7)

[Eric]

Thanks Ben, but this is not what I meant.
Via get_IDByte you can indeed grab the romcode of one particular device.
But once I know the romcodes of all attached devices, I need a way to address them individualy and therefore no function is foreseen in Flowcode.
I am talking about a Flowcode equivalent for the code "MATCH ROM" ( 0x55 )in the DS18S20 datasheet.

Best regards,

Eric

[Mikat]

I have noticed that if i have more than 1 ds1820 on the same bus,the program slows a lot,and i mean lot. If the program loop takes 1 second on 1 sensor adding the secon sensor could slow the program loop near to 3 second,the 1 sensor dont slow nearly at all. Could the reason be the "collision on the bus" ?
If so the MATCH ROM command is more than welcome,and the other hand,at least i need to know witch sensor sends the data...
Ben or Steve,is there any information about that monocrome glcd "real" component,witch can be simulated.

Mika

[Eric]

Hello Mikat,

It is true that a DS18S20 has a conversion time of 750msec. This means that if you have 3 sensors online and you let each sensor make a temperature conversion separately, the total time will be 3 x 750 msec.
However, it is not necessary to give each sensor a separate command to start the tempconversion. You can give 1 command to start the tempconversion on all sensor simultaniously. The only thing to do therefore is to detect the number of sensors online via the busreset -scanbus and getIDByte command, followed by a skiprom command and then a startconversion command.
The you can address each sensor separately with the GetTemp command.
What happens than is that every sensor starts his tempconversion simultaniously, which takes 750msec, whereafter you only need to grab the results. I use this to read 8 sensors and this is very fast.
But the architecture of you network is also very important to avoid retransmissions. Use only a lineair network! No star or stub configuration. This is very unreliable.

Hope this helps.

Eric

[Eric]

Hi Mikat,

Sorry, my mistake: read "busreset -scanbus and getIDByte" as "busreset -scanbus and getDeviceCount"

[Mikat]

I use the start conversion command all the sensors at the same time,so that is not the problem,the command usually follows the read temp macros,so the conversion is started after the temp is read,and the program runs a full loop,witch take like second,and then the temps are read... Maybe the problem is at the wiring the bus,i had to try it different,i havent check the scope what happened at the bus,so maybe i had to do that too...
But still,is the matchrom command only way to be sure that the "sensor order" is same all the time?

Mika

[Benj]

Hello

When starting up your system you can do a scan for devices, get the device count and then start a simple loop to initialise the addresses.

Ok so starting with device 1, read the 8 byte ROM address, decide which device it is in the chain based on the ROM codes, then in an array you can put that device x is address 1. Repeat for the other devices on the bus.

You will then end up with an array like this where the array index number is a reliable device position that will not change and the array data is the device index that can change on a reset or a rescan.

device[0] = 5 - boiler
device[1] = 1 - oven
device[2] = 2 - room1
device[3] = 4 - room2

Hope this helps.

[Mikat]

Ben,can this method keep the sensor in sama "place" even in restart and rescan?
Could you tell me more,i dont know how to create or use arrays...
And how about the monocrome glcd componen,witch i asked couple posts earlier?
And i sent you pm sometimes ago,asking is it how big job the rotate that monocrome glcd custom code 180 degree?

[medelec35]

To add a variable array, all you do is add variable as normal but straight after variable name add [] at the end with number of dimensions within brackets.

E.g taking previous post as an example:
Click add new variable, then in name box enter device[4]
When used in calculations, arrays is just like different variables with same same name and different values.
e.g
device[0] = 12
device[1] = 3
Number within brackets can be variables e.g.
var=2
device[var]=6
Therefore now:
Device[0]=12
device[1] = 3
device[2] = 6


If you are still stuck, I can post a Flowcode example, just let me know.

[Benj]

Hello Mikat

This will not keep the sensors in the same place on a restart or rescan but it will allow you to provide a function to sort the devices basen on their ROM codes.

Thanks for the comments on the arrays Medelec

[medelec35]

Thanks for the comments on the arrays Medelec

Your welcome.
Just hope my explanation makes enough sense for Mikat to follow and create arrays OK.