My Duinomite Mega Canview V4 equivalent Project

well i am kinda busy using the duinomite now as a charger controller
only problem is if i open source the code and something go's wromng then somebodys cars is on fire or house
so i am not going to open source it for that reason but i will open a topic in some time where i will explain what i have done
no canbus control of charger because mine is only analog current control.
and is sstill use the cellogs because monitoring 70 cells with 70 inputs al isolated is a bit expensif and a little to big i think
so i keep the cellogs for cell monitoring and the duinomite with the cellogs relay to control the chager

things like temp control ( high battery temp = charger off ) and with TO hihg temp a alarm and SMS to my phone ( already working )
and keep the charger connected so in like 24 hours after a charge it wil auto topoff again and stuff like that

i realy like this board.. if you did not started this canview i never would have got this board and look at what i am doing nnow ;_)
also getting a arduino uno this wil replace the duinomite at charger control and so i have the duinemite again vor canview

 

There are probably 3,652.1 different solutions if we're going to look at different dev boards!

As JLo pointed out this is really about a board that supports MMBasic "out of the box" - it lowers the barrier for entry for the non-professional programmer. If they "outgrow" BASIC then they can add stuff to the interpreter - or at that stage just look for another board. I'm not confident enough with the entire interpreter to know how big a job it would be to use on the board you identified - there would certainly be a rewrite of the graphics subsystem. Would it be just different pin assignments for the SD Card? CAN? Oh, and BTW, I got bitten by the "it even has 10/100 Mbits ethernet" when I purchased the eMega DuinoMite (now sitting in it's box). Sure, the hardware is there - what about the software stack so I can make a TCP/IP connection with some other device?

In my YaPIP project (with a thread on this forum) I'm actually using a similar board to the one you identified- but it's an Atmel dev board and it cost more . I wish I'd known about that one when I started - but I'm not going to switch horses at this point in the race. Oh, and the reason I went Atmel is because of getting started in micro-controller programming with an Arduino (a sw engineer with access to hw is a scary thing - just ask my business partner!!!)

My involvement in this thread actually springs from JLo's involvement on YaPIP. That's the beauty of open source - it "cross-pollinates" and starts other interesting off shoots. I'm using my 'Mite as a useful "head unit" which is dirt simple to program and I can hook up to the CAN bus. The "heavy lifting" will be done with the Atmel.

BTW, it literally took me about 1 hour to get a CAN data display working with the 'Mite. It took about a week to achieve the same thing with the Atmel board. That's the power of leveraging a high level language when it makes sense to...

 

Ack, not this tired old argument again!

I would open source this but you might get carpal tunnel syndrome while you compile it and then I'll be screwed!

Look at the top of almost any open source'd code and you'll see lots of valid disclaimers that have actually been reviewed by real lawyers. If you open source your code and use an appropriate license I believe you're safe. However, I ain't no lawyer - so it is of course up to you.

You're simply letting them have a free copy of text documents that detail your algorithms codified in a particular programming language. But nothing that they take from you is actually *doing* anything. It's no different than taking a book on bomb making out of the library - the author of the book isn't liable for who you blow up, nor is the library. (yeah, for the 'Mericuns among us we have the whole "Patriot Act" debacle to deal with!)

Now, if you were selling a completed charging control product then there's an implied requirement for safe and reliable operation for it's intended purpose when used in conjunction with the manufacturers instructions. At that point you need liability insurance in case someone does burn their house down and the major breadwinner goes up in the conflagration - then you'd better hire a good lawyer (actually the product liability carrier will hire a good lawyer for you!)

 

Well i dont agree selling books that explain how to make bombs
Just like you can find stuff online

With canview nothing really can go wrong or can it but controlling a charge proces is something else

Anyway even a 12 year old can write this code and relays on and off is easy
So dont think there is any problem there.

-Tapatalk

 

"With canview nothing really can go wrong or can it but controlling a charge proces is something else"

Sure CANVIEW can cause damage - it's talking on the CAN bus (it sends as well as receives) - send the wrong messages at the wrong time and you could probably cause bad stuff to happen (and it indirectly can control the charge process with CCL/CDL messages). However, my YaPIP project would certainly fall into a similar category as your charge controller because it will also include charge control algorithms.

So, how many cases of someone being sued for open source software causing physical damage have you heard of? Personally I haven't heard of any. The cases I've heard of are about people violating copyright - open sourcing something they have no right to.

There are numerous reasons one may want to, or not want to, open source something. Some of those reasons are more valid than others. But this idea of exposing yourself to risk seems largely to be an urban myth. It's also a little frustrating to tell us on this thread which is fostering open source development and the exchange of ideas that you're happy to use our open source work but you're not going to reciprocate. Again, that's your choice but you may want to be a little more considerate in how you communicate it.

BTW, I don't know if the 12 year old comment is meant to be funny but it's a joke that's passed it's prime (yes I know it comes from JLo's assertion but you keep using it out of context and it's just annoying now).

You've asked me for specific help to get you up and running with CAN on MMBasic 3.2c. I gave you that assistance free of charge. Please don't ask me for more help unless you're willing to open source your results. Sorry if that seems harsh. Of course, the nature of open source is that you'll have access to all the code so you should be able to work it out yourself anyway.

These are entirely my sentiments - I don't speak for anyone else on this thread.

 

If i would not have sad anything about that charger control i was working on, you would have not made the post you just did .
And did not feel that way about it/me

I just am a person that would not feel greet if Someone would burn there car down after reading my work.
Not just Because of legal reasons your talking about.
I just wurrie more about those kind off things.

I wanted to open a topic Buth then i started to think about it and changed my mind. Thats not a bad thing.

I did deside and thats Wy i was open about it that i would like to tell poeple it was easy to do and so on
Others would also Maybe go that road after reading it

But now i think i compleetly leave it after reading these comments



-Tapatalk

-Tapatalk

 

OK.

Now lets get back on topic...

 

Ok

-Tapatalk

 

Lpz

I don't know why you send 7E0 2 21 E1 before 7E0 2 21 42, but this first pid is used to get the number of dtc (according to berkeley xls)
You get the answer : zero dtc = 00 00

 

You can get it, for example, in this post

And this one also

 

Hi Lopez,

Maybe you could make a stacked set of graphs - that way you wouldn't need color. Also, sometimes it's easier to read stacked signals rather than having them all on the same axes - even when you do have color. Think of an old pen-based strip chart recorder. Of course you lose a certain amount of resolution - but I think in this case you want to look at general trends rather than detailed changes?

Just a thought.

 

OK - it's September and Labor Day here in the US. Which means I'm on holiday. And what better thing to do on holiday than code? (which is what I do for a living).

I've just run a successful test on filtering. Yay!

For those who care about the details: It turns out that I was chasing a red herring when looking at why "filters are not remaining set" - it may be a bug in the Microchip plib library but the "IsFilterDisabled()" func returns true even when a filter appears to be active. Or it might be me misunderstanding things regarding how to use the lib. It turns out the actual issue was my filter mask (not filter) was wrongly configured. One limitation with my just tested fix to the filter mask is that it will only work for SIDs (11-bits) not EIDs (29-bits). However the Prius only uses SIDs. I'll play with the mask configuration and see if I can make it work for EIDs

So now I need to tidy up the implementation, transfer it to 4.0 (I'm currently working in 3.2c still) and do some more testing. Then I'll write some documentation and provide some examples. And then - I'll be ready to distribute it.

But first comes dinner...

 

OK, attached is the first beta release of the new CAN commands. Included in the zip file are the following items:

- DMCAN2.hex - flash this onto your DuinoMite. It's built from the latest MMBasic 4.0 files and the hex is distributed with permission of Geoff Graham (overall author of MMBasic).
- CAN_Commands.pdf - documentation for the new commands
- Example[0-2].bas - example files. These should get you started.

A couple of notes:
- it's still in beta so if you find bugs then tell me
- it's open source and provided as-is - don't expect oodles of support but obviously I want to make sure it works properly
- this code is not backwards compatible with the original CAN implementation. However, an enterprising sole could make a simple compatibility library by implementing Frank's original commands as subroutines.
- the documentation refers to an additional 3 examples (one of which is the backwards compatibility subroutines). I haven't gotten around to them yet - but I figured you'd want me to distribute stuff sooner rather than later.
- Geoff has indicated that he'll include this implementation into the official MMBasic code base. This will allow inclusion in future releases from Geoff.
- The documentation file refers to "license X" - I'm still deciding on which license to use for the source code. The compiled hex is licensed in the same way as the original MMBasic hex. Use it in any way you want but it's provided as-is with no warranty expressed or implied.
- One bug I just noticed (but am too lazy to fix right now) is that although CAN FREE does free all memory it doesn't appear to clear the filters properly (so you'd need to reboot your DM between running example1.bas and example2.bas to see the differences)

Comments welcome.