Markus Posted March 27, 2018 Report Share Posted March 27, 2018 Hi I am new to the forum I would like to configure the CAN output format but i have still a few questions The output format i want to create is 11-BIT identifier + 8 Bytes payload All bits are 16 Bit Signed integer values in BIg Endian format I would like to define CAN ID's from 0x300 onwards to be output What i have so far is in the first tab "CAN Setup Mode": CAN Module :CAN1 Mode: User Defined Bit Rate 1 MBits/s Channel 1 Transmit User Stream1 CAN ID 300 Format :Normal This seems all still very clear to me (my assumption is that ID300 is just the Start adress right ?) Now when i define the frames : Lets say Frame 1 would be for ID300 Parameter Start Width Byte order Type Divider Multiplier Offset Parameter 1 0 16 MS First Signed 1 1 0 Parameter 2 16 16 MS First Signed 1 1 0 Parameter 3 32 16 MS First Signed 1 1 0 Parameter 4 48 16 MS First Signed 1 1 0 How would i make Frame two to be at ID 310 for instance , do i just change the offset ? Is my understanding correct that Offset is decimal ? so Decimal 16 = Hex 10 therefore offset 16 = ID310 ? ID 310 Parameter Start Width Byte order Type Divider Multiplier Offset Parameter 1 0 16 MS First Signed 1 1 16 Parameter 2 16 16 MS First Signed 1 1 16 Parameter 3 32 16 MS First Signed 1 1 16 Parameter 4 48 16 MS First Signed 1 1 16 Am i correct with this assumtion ? Quote Link to comment Share on other sites More sharing options...
Adamw Posted March 27, 2018 Report Share Posted March 27, 2018 No, this is not what the offset is for. For a compound message you will have to use a new channel for each new ID. So; Channel 1, Transmit User Stream1 CAN ID 300. Channel 2, Transmit User Stream2 CAN ID 310. etc. Unfortunately, that means you can only send 6 different ID's/Frames. Also note even though I used 300 in my example above, our ID's are in decimal so your "0x300" will actually be ID768 Often this limitation is overcome by using a sequential message, where many frames are sent using just 1 ID but with an "index" in the first byte (or somewhere else in the frame). Is your device capable of decoding a sequential message? Quote Link to comment Share on other sites More sharing options...
Markus Posted March 27, 2018 Author Report Share Posted March 27, 2018 Thanks for clarifying that . That was a good explanation .My Device is a Raspberry pi with CAN BUS hat and a Touch screen which runs my own programmed software and is used as a Datalogger as well as a Graphical Dashboard . I have already implemented The Haltech V2 as well as the Adaptronic Protocol in my device , so i wanted to make a CAN configuration file for the Link to output the data in either the Haltech or Adaptronic Format as i already implemented those in the software . So just for a final clarification for my use case i would define my 6 channels one per ID and leave the Offset always on 0 Quote Link to comment Share on other sites More sharing options...
Adamw Posted March 27, 2018 Report Share Posted March 27, 2018 The offset is just used to scale how the raw data is transmitted or received over CAN, just like the multiplier and divider do. An example might be a channel like ECT that needs to cover a range of say -30°C to +120°C but most CAN systems use unsigned integers. If you wanted to send this data out then you would put a +30 offset on it so that -30°C is sent over CAN as "0", and 120°C would be sent as "150", then of course you need the opposite scaling at the receiving end to translate it back into the right range. Quote Link to comment Share on other sites More sharing options...
Markus Posted March 27, 2018 Author Report Share Posted March 27, 2018 Thank you very much for the Awesome and fast Tech support :-) This was the exact info i needed Kind Regards Markus Quote Link to comment Share on other sites More sharing options...
Tim D Posted March 29, 2018 Report Share Posted March 29, 2018 I found this an interesting thread as I have been working on an MBED version of what Markus describes. I send 7 frames (one after the other) with an identifier in the first byte of the stream and another identifier at the end, which enables me to resync if corruption occurs. It doesn't cater for corruption in the middle of my data stream, which so far I've not resolved. Apart from using an oscilloscope to check the signal integrity, I'm not sure what to do? I had wondered about splitting my stream into smaller messages and use multiple IDs. Any ideas welcome? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.