Exactly, but at the same time it's probably easier to debug a problem if someone described the problem rather than said, "I think that you ignored the last byte that the ECU sent you in function X". You all use Firefox (don't you !?) and even though you can look at the source code I bet that you never have. If there's a problem, report it and we'll fix it. If you really want to see the source code, contribute something to the project and you'll get the same access to it as the rest of us. There's nothing secret squirrel going on here. As far as I'm concerned the discussion about open source is over. I hope that if you're interested you take the library in good faith and make something amazing with it. As NewKleer said, (I'm quoting him a lot lately so he must be a good guy), "Reflector is your friend." Good God it can even create a compilable project for you!
Here's the diagram. If you concentrate on the left-most application, this project is primarily concerned with creating the green modules. The pink parts are left up to you or others to create. We may complete the project (i.e. the pink parts), however that is not our primary concern. I chose the other two applications because most of you know them and what they do. You will also note the source is not available for these, and it is not easily possible to interface to them. If you want to use the features they provide, it is an all-or-none approach. You can use it - or not be able to get the info from your car. You can't customise the output (other than different guage style etc). Our approach is very different. We will give you the means to get the data from the car. How you present it, and what you do with that data is up to you (or other developers).
It's easy, it's fast, it's free, it's supported on all current platforms. What's not to like? Actually don't answer that, PM me if you any real issues.
I'll agree with you here. .NET is a good framework to use, It's come along way since the early days. I used to hate it too (memory hog and all that), but .NET 2+ is fine.
Unfortunately, no. vbevan was doing the coding but got stuck when he needed to connect to an ECU on his desk. And I used my spare ECU just yesterday as my tuned ECU now doesn't want to work I told him all he needed to do was connect a bunch of wires to a 12v supply and another bunch to ground and all should be ok, but he wasn't sure. It's not dead, but also not moving as quick as we would like.
Vbevan? Just Evan (Evz). It's not going as quick as we would like but the collaboration has been a bit limited so far. I have a spare ECU if someone would like to wire it up (hint hint ) and then we can go from there. If it's simple to do then it will be even simpler for someone with some electronics/electrical knowledge. Get my ECU, connect up the power, connect up the Consult port wires, read the equipment number with existing software and then ship it to me. I'm willing and have made a start but I've also expressed what I can't do and what I need assistance with. The ball is in your court.
Have a look at Silicon Chip October 2009 which describes a USB I/O controller using the ATMEGA32. The ports of that chip can be assigned to read or write back to the processor and then back to Windows through the USB port. The control programs are C or BAT under windows, or Linux style BASH files if you like the additional features. The article describes a useful way to interface external devices to and from Windows (or Linux ) . That type of approach using an interposed microprocessor seems to give you everything you need in the hardware interface I/O sense. As the article says I guess I should say the above quote is copyright Silicon Chip. I parked next to an E Class Merc today and its mirrors were folded in. When the owner came back and pressed his remote to open the doors, the mirrors automatically folded out again. Cute I thought. While there are a lot of electro-mechanical ways to achieve that result, a configurable software based approach seemed doubly cute. Anyway, I have built the Silicon Chio I/O controller and when I get some time (i.e. the overseas visitors go home ) I will have a play with it and start experimenting. Using a common hardware interface along these lines would make your project a software exercise with open source modules being contributed from anybody with the skills and the time.
We're focusing primarily on software. The hardware has already been done for us (all of the USB/Comm Port to Consult plug stuff that is around). We want to make a library that is easy to use for multiple applications. If someone doesn't want a PC in their car they could always use our solution with an embedded .Net piece of hardware like the Usbizi - http://www.ghielectronics.com/product/113 The possibilities will be endless and accessible to everyone. We just have to get our act(s) together and get the library completed. At this point in time I think it is about 30% there with plans of ramping up development very soon.
.net micro? thats a bit different to the normal .net framwork, you sure everything you need to do will be supported?
Hey Dave, I don't think that I'll be making that cruise. Too far south and I'm already booked out for Sat and Sun. I'm leaving Perth on Mon and have a lot of loose ends to tie up. If you PM me your address I'll post the ECU, ECU plug, and Consult plug for you to wire up. Then you can post it to a Perth, or Singapore address if you are willing and I'll take it from there. Something like this would be ideal: I will supply the 3 green pieces and you can wire them up and test them. After that there is nothing stopping us.
To use the library all we need is to be able to connect to the Consult port. The usbizi has an SPI so there should be no problems. I wasn't suggesting that that is the way that I would go, only what someone could do if they didn't want a full PC in their car. Let me add NewKleer (does anyone know your actual name ) that I hold very highly the work that you've done. But it's closed and that we're aiming for is something that is available to everyone. If you would like to get involved then you're more than welcome (Even if it's just in advice when we hit a curly one).
i mean if youre making it for the .net micro, thats going to be more difficult (i assume, havent looked into micro much) compared to .net compact or normal .net...id aim for no lower than .net compact framework given anyone developing for .net micro could knock out the code they need pretty easily ive actually had it on the cards for quite a while, once ive upgraded to .net 2.0, to rearrange stuff so the ecutalk exe itself is able to be used as a library and/or ability to code your own gauges. only problem is moving from .net 1 to .net 2 leaves behind pocket pc 2000/2002 users, so wanted to get alerts and maybe some active tests implemented before upgrading to .net 2.0. cant wait till i do cause using vs.net 2003 compared to 2008 is quite a hit to productivity. i dont really have time to get involved (what time i have would be better spent getting ecutalk in order) but if you do get stuck with anything you can ask here and i can help out or whatever. though 95% of the time ive spent has all been on the UI etc logic, the base consult stuff isnt all that difficult. Peter
Many thanks. I hadn't appreciated you were starting from the other side of the Conzult port/serial interface. I also hadn't appreciated that the specs of that hardware device were available to bridge into. Nevertheless, I am looking forward to my experiments with the Windows/USB IO interface and see where that takes me. At the same time I am extremely interested in seeing your function library fully developed and exploited. I was a vs .net 2003 user and I got TPO when that wouldn't work under Vista. Microsoft always find ways for us poor users to spend more money. Nevertheless, I kept the old VS it in a bootable XP partition, but I know I am missing out on the productivity improvements of later VS releases. Under the Silicon Chip IO device, I can write raw C (or C++ under Linux) without using a .NET environment at all. At my level of proficiency, that provides plenty of scope to have some fun. Keep up the good work!
We all use Vista 64 at work. I use VB6, VC6 (only in a read-only mode of old code), some C# 2005, less C# 2008, VB 2005, but primarily VB 2008. I also have to use VB 2003 from time-to-time, though only if I have to. Mostly everyone else only uses VB 2003. Again, this is all on Vista 64. I suggest that if you still want to use 2003, then go for it. Disable UAC, modify the IDE shortcut properties to "run as administrator", then you're good to go. Also, check out the following sites if you want to use software freely provided by Microsoft: http://www.microsoft.com/web/websitespark/ http://www.microsoft.com/exPress/
Yep you can get them to work. I use VS C# 2008 under Win 7 Enterprise. All sweet. The good thing about a .Net Library is that you can use it with VB, C#, managed C++ if you want. If we make if COM visible (which we will thanks to this post) you can even use it from VB6, Excel and Word. There's also no reason why you can't use it on a windows mobile device. Something for everyone. Here's how we see it being used. Code: using NissanZ32Consult; using System.Diagnostics; namespace Console { class Program { static void Main(string[] args) { bool appRunning = true; //ConsultComms has the correct serial config by default for the Z32 but can be changed if required. ECU ecu = new ECU(new ConsultComms()); //Default is metric so doesn't really need to be set. ecu.Units = ECU.EcuUnits.Metric; string partNumber = ecu.PartNumber; //Display it or what ever. //Hook up the event handler to receive notification of new values. ecu.NewStream += new ECU.OnNewStream(ecu_NewStream); //Opens comm port and initialises comms with ECU. ecu.ConsultComms.Connect(); if (ecu.ConsultComms.IsInitialised == true) { //Check the codes. CodeInformation codeInformation = null; foreach (int code in ecu.DiagnosticTroubleCodes.StoredCodes) { codeInformation = ecu.DiagnosticTroubleCodes.GetCodeInformation(code); //Do something with the code info string n = codeInformation.Number; string d = codeInformation.Description; string a = codeInformation.Advice; string t = codeInformation.Title; } //Codes remain available and can be reread if required. ecu.DiagnosticTroubleCodes.Refresh(); //etc. //Get some data. //Upto 20 at a time. Limitation of the ECU. ecu.StreamingEngineParameters.Add(ECU.EngineParameter.RPM); ecu.StreamingEngineParameters.Add(ECU.EngineParameter.Speed); ecu.StartEngineParameterStream(); while (appRunning) { //Program continues to run. Each time there is a new set of paramaters streamed the event handler ecu_NewStream() is called //allowing you to do what ever you want with the values. //While the app is running you could stop the stream if you wanted to, add extra parameters and then restart the stream. } ecu.StopEngineParameterStream(); ecu.ConsultComms.Disconnect(); } } static void ecu_NewStream(object sender, ECU.StreamEventArgs e) { EcuParameterValue parameterValue = e.StreamedValues[ECU.EngineParameter.RPM]; //display the values string units = parameterValue.Units; double actualValue = parameterValue.Actual; double rawValue = parameterValue.Raw; bool isValidValue = parameterValue.Valid; parameterValue = e.StreamedValues[ECU.EngineParameter.Speed]; //display the values units = parameterValue.Units; actualValue = parameterValue.Actual; rawValue = parameterValue.Raw; isValidValue = parameterValue.Valid; //And so on... } } }
