I just want to check that I haven’t missed something obvious before I start implementing things in an overly complicated and resource expensive way…
Is there any sort of arbitrary parameter/variable that can be defined in the system? I am thinking of something along the lines of the way the parameters on the keyboard w/ encoder are implemented but not tied directly to using a keyboard. Something where I can say “On the leading edge of Fn_X equals true set parameter_y to number_x” where X could be a constant or a “parameter_y + 10” or the value of a channel at the moment in time where Fn_X went true. Something that I could then save to one of the 20 stored channels and restore on startup.
The only things I can see doing something similar to this are:
Keyboard w/ encoder and parameters; but that dedicates an encoder and a physical button for every value I want to store and is only adjustable by physically turning the dial, not programmatically, and only in sequential order (adding 3 means 3 clicks, no arbitrary jump from -5 to +8)
Counters; but this has the same limitations of the keyboard with regards to only having sequential operations.
Using a triggered CAN custom export to broadcast the value I want and then a custom import to write that value back to a CAN input channel set to “use last value” (no timeout). This seems like it would provide all the functionality I want (it even supports saving to flash and restoring last value on startup and setting a default if that fails) but seems a bit hinky to be using the CANBus to talk to myself just because it is the only want to arbitrarily input a value, setting aside it also burns a CAN Message object, Input, output, and (a tiny bit of) bandwidth to do so.
It is possible that if there were some way for numbers/maths channels to reference leading/falling edge in their choose logic operand it could be achieved with that but near as I can tell there isn’t currently any (straight forwrd) way to keep an x = x+y statement from firing with every evaluation cycle while a button is depressed instead of only on the leading edge. And, even then, there would be issues (or at least more complications and burned resources) defining a default state if the saved value can’t be restored for some reason since maths channels don’t have anything like that built in.
Don’t get me wrong, I love the ADU and EMU for the level of arbitrary control they afford me relative to other manufacturers but I haven’t been this resource constrained on a computer since before the Commodore 64.
I don’t think you can save canbus input in the stored channels tab. Last year I was trying to save the battery level of the tpms sensors (info via canbus) and it was not possible.
I use switches for a similiar function. When I press the button, it increases the fuel tank size for the vft refuel. But it can only go up(or down) by 1. What is the number range you are tyring to use?
Could you give an example of the logic you are describing? I think it’s not too complicated to implement with a few numbers and a function, but maybe I didn’t fully understand what exactly you need, so an example would be very useful.
The first example I came across was for the vft.FuelTankSize channel. If I would like to have a +5G (which is the specified size of our dump can) and -1G button (to allow for any unforseen adjustments) for the driver to set how much fuel is going to be added at the next pit stop.
So ‘n_FuelToAdd’ would start out as a default of 5 but a button event would execute (effectively) n_FuelToAdd = n_FuelToAdd +5. Pressing the other button would produce n_FuelToAdd–.
Then when the driver pulls into pits they are required to shut down the car, so this would need to be saved. Then when the new driver gets in the car and turns it on the value is restored. There would be another maths channel that would be n_NewFuelLevelRaw that would be vft.FuelRemaining + n_FuelToAdd and then ANOTHER n_NewFuelLevel maths channel that would clamp the Raw channel to the maximum fuel cell capacity. This is what the dynamic vft.VirtualTankSize channel would be set to.
Now I understand that this example could be accomplished using a switch, though it would mean only having +1 and -1 option but I was just trying to understand if the following sort of logic was possible for a number:
number n_FuelToAdd
value=
n_FuelToAdd
+
choose(k_AddFuel,5,0)
+
choose(k_RemoveFuel,-1,0)
The problem (as I see it) with this being that the choose statements would be true so long as the k_AddFuel button was pressed and so 5 would be added at a rate of 500Hz instead of just once per press. Being able to evaluate something like
choose(k_AddFuel.Rising,5,0) is more along the lines of what I am trying to do.
I have several instances of this where there is a “constant” being used as either a trim coefficient for various functions or to input things like the target time for the stint which I would want to be able to adjust on the fly and have saved/restored between power cycles. There are ways to work around most of this, they just seem rather resource expensive in a system that offers a maximum of 100 operations as well as needlessly complicated if there was a way to execute event-driven math operations that I was not seeing.
I don’t think you can save canbus input in the stored channels tab. Last year I was trying to save the battery level of the tpms sensors (info via canbus) and it was not possible.
Q for EcuMaster guys… is this true? The saved channel configuration pane will allow me to select a CAN import channel as a target but I haven’t yet had the opportunity to test if it actually works or not.
didn’t hear back after my e-mail.
i think the issue is, that there is a default value for canbus input channels, which overwrites the autosaved channel.
The use previous value is only in case of timeout.
I direct wired my ADU to battery, with a seperate on/off switch, so when I stop my bike (ignition off), ADU can stil be running/recording/displaying stuff) It could work for you during pitstop, not sure about the rules obviously…
i think the issue is, that there is a default value for canbus input channels, which overwrites the autosaved channel.
The use previous value is only in case of timeout.
Gah… that kind of makes the whole saved channels thing useless then. I wonder if it is by design for some reason or if it is simply an order of operations bug in the firmware where if they just change the startup so that defaults are applied first, then saved channels are loaded AFTER that it would work fine.
it works great for non canbus channels. like numbers or switch states.
It technically works with canbus, but since it overwrites everything on boot, it’s never gonna work in reality. I guess design oversight, but it’s fine for a beta feature
In the project attached, fuel is added/subtracted only on the rising edge of a specific switch. I think this is the easiest way to achieve what you need at the moment—if I understood your request correctly.
