Bitmasks for CAN transmit signals in non-compound messages

[mjohn143]

Hello, is there a way to apply bit masks in non-compound messages while transmitting (like while receiving)? I am attempting to use a C185 to gateway OEM CAN signals from one bus to another in order to supply all the necessary signals, checksums, and counters to a OEM module. I am able to get all of the signals, perform all of the calclations, etc. but I am having trouble correctly packing the signals into the approperiate CAN messages due to the message format (multiple 2,3,12,and 16 bit signals in one message).

It looks like bit masking can be done with the compound message tool on the transmit side, but is there a way to use this tool without sending a signal ID?

Thanks in advance!
Matt Johnson

[adrian]

The easiest way to do this is to use advanced maths to position the required channels within an output message. So for example let say I have a 3 bit channel and a 10 bit channel to be sent in one 16 bit message where the bit offset for the 3 bit channel (channel 1) is 14 and the offset for the 10 bit channel (channel 2) is 11.



The equation in advanced maths becomes: 'Output Channel" = "Channel 1" * 4096 + "Channel 2" * 4
Where the multipliers are 2^the LSB of the channel, so 2^12=4096 for channel 1 and 2^2=4 for channel 2.

[mjohn143]

Adrian, thanks - that makes a lot of sense, and certainly looks easier than the brute force method that we ended up using with the bit combine function...

Two questions:
1) Any thoughts on which method is more CPU efficient (bit combine vs. channel maths)?
2) How are channel calculation rates and timer calculation rates set?

I am calculating multiple counters and checksums to be broadcast at 100hz on CAN, the counters are all fed by .01s timers that reset at .15s, and multiplied by 100 to give a 0-15 signal that is supposed to update and be broadcast every 10ms and increments upwards each time until it resets and starts over - unfortunately, these functions appear to be only recalculating every ~40ms (but are broadcast on the CAN bus every 10ms). Any ideas on why the calculation frequency is so far below the broadcast frequency or ideas on how to control the frequency of the calculation of variables? Would direct math calculations vs. lookup tables or logging rate of the associated channels make a difference in the rate that the signal is calculated/updated?

Thanks again,
Matt Johnson

[adrian]

The dash uses the following calculation rates:

Timers: 100Hz
Advanced Maths: 50Hz
Channel Maths: 50Hz
Bit Combine: 50Hz
User Condtions: 25Hz

I ran a quick test to show you how the timing is affected by the above calculation rates (see here.) The "Bit Receive" channel is simply the "Bit Combine" channel sent out of one CAN Bus at 100Hz and received on another (at the transmit rate). All of the calculations are based off the timer channel except the bit combine which is using the user condition channel.

Adrian