Page 1 of 1

Motorola bit format incorrect

Posted: Fri 20. Jul 2018, 14:34
by gparks
I have run into an issue with the PPCAN-Editor. If you are trying to remap bits, it works normally if you are using intel bit format. The example I have provided takes in a message, creates a variable that is 16 bits long and starts at byte 0 and bit 0. Then on CAN-2 I output a message with a different ID that has a variable that is 16 bits long and starts at byte 0 and bit 0. Intel works correctly and just outputs the same bits on CAN2, however in motorola configuration, the bits are right shifted 15 bits and 1 bit is taken off the 16th bit and moved to the -1 bit location... I have screenshots to help explain.

Is this just broken in the software? Motorola should reverse bit storage but it should not be shifting 2 bytes and overflowing a bit. Please advise

EDIT: The issue was some kind of software glitch. I transferred the configuration to a different computer to confirm it was not a hardware issue on my end, and the output was still the incorrect output as Start byte 0 start bit 7 is the correct format to use. However, after changing the start byte and start bit and then setting them back to 0,7 and flashing, it now works correctly. The change must not have been updated in the new flash file.
So if you end up with a similar issue try changing all values, flashing, then resetting them to the correct values and flashing. This forced them to update in my router.

Re: Motorola bit format incorrect

Posted: Fri 20. Jul 2018, 15:32
by S.Schott
Hi there.

Motorola counts the other direction.
For the Motorola value, please change start bit to 7.

Re: Motorola bit format incorrect

Posted: Fri 20. Jul 2018, 18:49
by gparks
I am not sure what changing the start bit to 7 will do. Here are pictures of that configuration, with the problem still persisting. if we are in the same format (moto to moto) from input to output, and are copying the exact same bits, the message comes out different. switching from intel to motorola should not cause any issue as we are just mapping the same bits to the same bits in the outgoing message