My Duinomite Mega Canview V4 equivalent Project

Yes, I think it's supposed to be that data. I don't think you need to send it as a 29-bit ID (extended frame). Just a regular 11-bit ID (standard frame).

So, I think the BASIC should look like this

Code:

dim txOK
dim data(8)
data(0) = &H21
data(1) = &HCE
cansend &H7E2, 0, 2, data(0), txOK

After sending that I'd expect to see a message with ID &H7EA on the bus (the response ID is the request ID + 8).

Trouble is I tried that and it didn't work.

I've also ordered a Y-cable so that I can hook an ELM device and my DM to the bus at the same time (I'm not ready to dive into the CAN wiring harnesses yet!)

 

My torq app is also set to 11 bit
And it can request battery cell voltages etc

-Htc Tapatalk ( sorry for auto spell correct )

 

I think you need the second one but I think the cansend should be:

cansend &H7E2,0,3,data(0),txOK

 

Update:
1) My DM refuses to go into bootloader mode so I can't flash the V4 beta build to test. I've sent it to JLo so that he can test it.
2) Good work by JLo on the PID requests. I thought I'd tried that variant before - but I'll try again tonight to be sure. Hopefully JLo will beat me to it
3) Still debugging my HSI code (jlo I've made several bug fixes to what I sent you - but the CAN message retrieval pattern is the same)
4) I looked at CANVIEW file and made some suggestions on how to speed it up. However, I'm seeing similar issues with HSI and so I suspect my first attempt to speed things up still isn't fast enough. Which got me thinking about adding some more CAN commands to [MM|DM]Basic (see next)

 

Both my code and JLo's code seem to be operating too slowly to reliably retrieve the CAN messages. I'm sure there are a lot of other approaches we could try within our BASIC code and one of them might work. I'll try some of 'em.

However, I think I may also try to enhance the existing CAN implementation. I'll leave all the existing commands as is. But I'll add some additional ones:

Code:

 
CanOpenWithHWFilter(speed, msgType, hwFilter, openOK)
 
speed = bits per second 10,000 to 1,000,000 (500,000 for Toyota Prius)
msgType = 0 for 11 bit only, 1 for 29 bit only, 2 for both types
hwfilter = bit mask to apply to incoming messages
openOK = returned value: 1 for successful completion, 0 otherwise
 
e.g. CanOpenWithHWFilter 500000, 0, &B01010101010101, openOK
 
This command will use the low level message filtering built in to the CAN hardware. 
Only messages of msgType that match the bit mask hwFilter will be placed into the
internal CAN message buffer.
 

However, I'm not sure if the HW filtering at this level is flexible enough for our purposes because we want a wide range of different messages. That means we'd need to set a wide filter and that, in turn, means we'll still catch a lot of other messages we don't want.

These next three commands push the monitoring of the CAN messages down into the C code. If you're familiar with the Torque application then these commands are equivalent to how you add PIDs.

Code:

 
CanMapAttribute(attributeName$, msgId, translation$, addOK)
 
attributeName$ = unique name used to retrieve the value
msgId = message Id for an unsolicited message (i.e. not a PID request) that contains the attribute
translation$ = formula to take raw bits and turn into attribute value
addOK = returned value: 1 for successful completion, 0 otherwise
 
e.g. CanMapAttribute("rpm", &H3C8, "2:U16:v/8", addOK)
 
This command will add attributeName$ to an internally stored map of attributes
of interest.  Each time msgId is received the internal map will be updated with
the new value.  The value is calculated according to the translation string.
The translation string is made up of 3 parts each seperated by a colon (:).
Part 1 = starting byte within the 8 byte payload, zero based
Part 2 = data type of raw data e.g. U16 = unsigned 16 bit, S12 = signed 12 bit
Part 3 = formula to convert the raw value (denoted by v) into a value
 
---
 
CanMapAttributeFromPID(attributeName$, ecuId, mode, pid, translation$, period, addOK)
 
attributeName$ = unique name used to retrieve the value
ecuId = id that should be placed in the PID request
mode = PID request mode
pid = pid requested
translation$ = formula to take raw bits and turn into attribute value
period = time between requests in milliseconds
addOK = returned value: 1 for successful completion, 0 otherwise
 
e.g. CanMapAttributeFromPID("MG2 Power", &H7E2, &H21, &HC3, "(256*A + B - 16383) * ((32*C + 0.125*D - 500)*0.7376) / 5252", 500, addOK)
 
This command will add attributeName$ to an internally stored map of attributes
of interest.  Once every period a PID request will be sent and the system will
retrieve all parts of a multi-frame response.  Once all data has been retrieved
the value is calculated according to the translation string.  The translation
string represents a formula to apply with A = first byte, B = second byte
etc.
 
---
 
CanGetAttribute(attributeName$, val, getOK)
 
attributeName$ = name of previously added attribute (can be a PID or an unsolicited value)
val = returned value: most recently calculated value of the attribute
getOK = returned value: 1 for successful, 0 otherwise
 
This command retrieves the latest attribute values from the map
 

Let me know what you think.

 

It looks like we might only need to do the "CanOpenWithFilter" approach initially. The other approach would be nice to add at some point.

Looking at this picture:


1) I'm confusing "Filters" with "Masks". A filter is for a specific ID a mask is for a range of ids.
2) We can have 32 filters per CAN module and we can have up to 32 message buffers.

The way things are configured at the moment all messages are getting through (a Mask of 7FF) and are all flowing into one channel buffer.

I'm changing my naming convention to CANOPENEX (EX standing for EXtended functionality) - you'll be able to set filters and masks and you'll also be able to assign message buffers. I'll also create a new CANRECEIVEEX command that will allow you to specify which message buffer to read from.

More info later...

 

can this board also be used to make a 70+ cells BMS to control the charger CANBUS or just analog current control?
whats the max analog voltage sensors that can be used?

 

I doubt this is helpful however a little reflective. Recently, while driving low speeds with Enginer4kwV6 (On) and MFD full green I had the similiar experience you have described only without Canbus . I lost throttle/accel/pedal control and forced into neutral. I flipped(turned off) enginer. I attribute my issue to high temps and have only used my Enginer 4kw V6 when outside temps is below 100 degree F so basically 99 and below.............

 

Updated video?

-Htc Tapatalk ( sorry for auto spell correct )