Outputs using can Inputs as conditions not latching

[b3tuning]

Sorry if I'm overlooking something simple.. If I have an output control channel set to a Can Input, the output works with the exception of latching into the last known state when there are no more can messages...

If I have an output control set to conditions, ie
PDM.CAN Inputs.Message 0.Byte 6=true
AND Ignition Switch.Voltage=true

then the output is only active when processing the can message, even if the can message is always true for the relevant Byte. So the output is off except when it receives and processes the can input, sees the conditions are met, turns on the output, and then immediately turns off the output until it gets the next can packet. The can packet is sent every 10ms, and while testing the relevant byte is always 0x01.

Any idea what I'm doing wrong? I've attached the pdm file I'm testing, the output channels in question are 10-12

[b3tuning]

Here's the ppm file I'm testing

[b3tuning]

Quite a few views and no responses... So the solution DID end up being something simple I overlooked..

instead of output control set to conditions, ie
PDM.CAN Inputs.Message 0.Byte 6=true
AND Ignition Switch.Voltage=true


It needed to be
PDM.CAN Inputs.Message 0.Byte 6=true
AND Ignition Switch=true

In case I'm not the only idiot, hopefully this can help someone else!

[Stephen Dean]

Hi,

I was looking at the file just before, but I was concentrating on the CAN Message and was planning on setting up a test for it. I haven't seen a PDM configuration where the raw CAN message has been used as an input like you have, normally a CAN Input is setup and used for this. I was going to test to see if there is any difference in the behaviour of the control message by doing this, I do not believe that there would be, but I'll probably still test it anyway.

[b3tuning]

I was going to test to see if there is any difference in the behaviour of the control message by doing this, I do not believe that there would be, but I'll probably still test it anyway.

Stephen, thanks for taking a look. I didn't setup the Can Inputs as it seemed like an extra step to doing what I needed. Correct me if I'm wrong, but you setup the can input for offset and mask to get the desired data, and then you setup the condition to use the Can Input Channel and then operate on that desired data (==, !=, etc).

It works similarly whichever way you go about using data out of the CanBus stream, so kudos there. The benefit of the Can Input channel is how timeouts are handled.

In any case, this allowed me to free up physical inputs and I just add more code to my shifter module to offload tasks via can bus instead.

Thanks for a great product