programming TMEX on IO 8 channel, random answers

[frank10]

I wrote a prog in C with the TMEX api to drive a Hobby Board IO 8ch.

I have two questions:

1) (not crucial)
when I control the logic or output state I get a sequence of 1 bit to tell the off state of relè.
Shouldn't be the opposite: 0 means relè is off?
I.e:
relè 2 is on: I get a byte of 253 -> 11111101 that reversed gives me the 0 on 2nd relè: 10111111
shouldn't be more logic having 00000010, 2nd relè is 1 that is electrified-on?

Idem for the output state. Instead the activity state I get correctly the 0: 01000000

2) (the real problem)
I got strange behaviour randomly:
Normally I get the behaviour as I described before:
es: relè 2 on:
logic state: 10111111
output state: 10111111
activity state: 01000000

Sometimes I get wrong bytes:
all 1 in the three states, or wrong activation relè.
This is very disturbing as you can't be sure which relè you electrified or which relè is active!

I think this could be interference problem in the net.
What can I do to solve this?
I put the part of code I wrote for the logic state, the output and activity are the same TMTouchByte:

	TMAccess(session_handle,state_buffer);
	short rt;
	unsigned char CRCByte ,	CRC16;
	long i;
	
// Read PIO Registers Cmnd 
		TMTouchByte(session_handle,0xF0);
		CRCByte = 0xF0;
		CRC16 = TMCRC(1, &CRCByte, CRC16, 1);
	  
//Issue first byte of required register (PIO Logic State) 
		TMTouchByte(session_handle,0x88); 
		CRCByte = 0x88;
			CRC16 = TMCRC(1, &CRCByte, CRC16, 1);		 
   
//Issue second byte of required register
		TMTouchByte(session_handle,0x00);
		CRCByte = 0x00;
		CRC16 = TMCRC(1, &CRCByte, CRC16, 1);


// pio logic state 

		CRCByte = TMTouchByte(session_handle,0xFF);
	CRC16 = TMCRC(1, &CRCByte, CRC16, 1);
	if ( CRC16 < 0 )
	 printf("ERR=%d", CRC16);

That last CRCByte is not always correct.

The CRC I copied from another example but I don't understand well how it works. I tried the last CRC16 line, but doesn't get the error of the wrong CRCByte.
For example, with 2nd relè on I must get 253, instead sometimes I get 255 but the CRC16 isn't bad.
I tried also the TMTouchBit in a for cycle. Idem.

I need some advise, Thank you.

 

[frank10]

I discovered what it was:

I tried to disconnect a part of the net and now it works well.

I have a serial network in a stubbed topology:

USB master --> 1xIO --> 4x sensor Temp --> 1x Dualcounter --> 2x sensor temp

This part is about 79mt cat5e cable +sensor , and this works

The other part of net is another 30 mt with 2x Sensor temp.
With that, the io makes that strange behaviour.

But it should be about 100-120mt, it should be correct with the sheets, no?

What could I try?
I read that someone put 100-150ohm resistor in the stubbed lines, but it seems not compatible with the master usb.


Anyway, apart this hardware problem, I'm interested in knowing better the CRC check.

 

[frank10]

Eric, the power injector could solve this problem?

Or maybe the 6 channel hub?

Nobody knows about the CRC?


Thank you.

 

[sda]

I don't know if this will help you, but here it is anyway. This is how the CRC is processed for the DS18S20 temp sensor. On this device, the CRC is of the scratchpad area. As each byte of the scratch is read, its put into the CRC using the TMCRC() routine. Then the CRC byte is read off the wire and added to the CRC. The final CRC should now be 0. You'll need to read the spec sheet for each device to determine its process.

[codebox]
' send read scratch command
TMTouchByte xxSessionHandle, &HBE

' crc summary
crc8 = 0

' read scratch
For i = 0 To 7
' buf = (unsigned char) TMTouchByte(session_handle,(short)0xFF);
scratchpad(i) = TMTouchByte(xxSessionHandle, &HFF)
' add to crc
crc8 = TMCRC(1, scratchpad(i), crc8, 0)
Next i

' check crc
crcbyte = TMTouchByte(xxSessionHandle, &HFF)
If TMCRC(1, crcbyte, crc8, 0) <> 0 Then
xxErrorMessage = FormatErrorMessage(ClassName, procname, _
"CRC mismatch")
Exit Function
End If
[/codebox]

 

[frank10]

Thank you sda.

So, the final CRC is the sum of all the CRC of the bytes read and this cumulative CRC needs to be checked at the end with the CRC byte at the last byte read.

I made it wrong comparing the CRC of a single byte read.

Ok, I will try this way.