Communication Errors with MS3 and MShift

[LT401Vette]

That all looks fine.

What I was asking is what TunerStudio Driver do you have selected in the TunerStudio dialog:
Communications --> Settings

That can effect the interWriteDelay timings when tsWriteBlocks is off..

[mill383]

Ok, here is the settings I use in TS for Com1 (serial USB adapter). I also use the same settings for built-in USB (MS3pro) and for BT. I think these are the correct settings based on what I've found on the forums. I've tried just about every combination, and this seems to connect most reliably.

driver5.jpg

Dave

[jsmcortina]

OK,
back onto the CAN passthrough.
I spent the last few days investigating the issue (and Jean looked recently also.) We concurr that something isn't working well. Debugging is a complete pig.

There are a combination of issues.
1. Megasquirt-CAN seems to respond badly when the CAN bus is heavily loaded.
2. Megasquirt-CAN is inefficient and uses twice the number of packets to fetch data (instead of just listening for a broadcast, it asks for it.)
3. TunerStudio over-reacts when it receives a CAN timeout message.

I've discussed #3 with Phil and hopefully he can do something about that.

For #1, I'm considering re-writing the CAN code so that it can handle a busy bus more gracefully.

For #2, ideally we should switch to using 11bit CAN broadcast messages. MS3 already has support for selective broadcasts and receiving. The developers need to consider if this is a change we can make in the short term. If you are using firmware that isn't from the "MSEXTRA" family, that could present a problem.

James

[mill383]

In an attempt to be more efficient with CAN usage, this is how I have my system setup:

I physically have 4 CAN devices:
1) MS3Pro
2) MShift (GPIO)
3) EGT_CAN
4) TinyIOx

Under Project Properties > CAN Devices > I only specify one CAN Device, that being MegaShift, CAN 1. I have the Disable RanTime Data unchecked, so that it has its own Dashboard Tab. The other 2 CAN devices I do not list under project. I have them configured under CAN Parameters menu under the CAN ADC group, and then identified under the Generic Sensor Inputs window. I am assuming this is the more efficient way to handle CAN data?

The recent bench testing I've done did have all CAN devices connected, but I'm not convinced CAN is the root cause of my issues. I am going to pull the fuses for all devices except MS3Pro, and repeat the Opti Triggered vs Basic Trigger test and post the results.

Dave

[mill383]

Ok, here is something interesting.

The underrunncounts that I observed during the recent RPM sensitivity study has nothing to do with the opti. I just tried the same setup (James "off, off, 4" setup) and get the same rate of occurrence of underruncounts. When I switch back to the default "on, on, 0" config, then all is clean. No overruns, no underruns. This is with opti not spinning and all CAN devices powered and communicating. For runtime datarate I get 35-40 samples/sec using the serial USB adapter.

When I turn on the Opti, then I get overruncounts about 1 every 2 secs, and whose rate of occurrence is unaffected by rpm.

Next, I power down the system, pulled the fuses for all CAN devices (except MS3Pro) and applied power. Runtime Data rate jumps up to 65-80 samples/sec. With no opti spinning, as expected there are no overrun or underrun counts. With opti spinning, then I do get overrun counts very similar to when all CAN devices were connected. Next, with the opti still spinning, I change from opti-triggered to basic trigger and turn off sequential stuff, etc. Cycle power to MS3Pro and the system comes up healthy. No overrun or underrun counts. Let it run for 5 mins, no problem. Vary the opti rpm from 100 rpm to 7000 rpm, no problem. No counts.

Next, de-power, insert CAN device fuses (MShift, EGT, Tiny) and apply power, recent projects > camaro (to reboot TS). Opti still spinning, basic trigger. Runtime Data rate drops down to 35-40 samples/sec, as expected due to CAN traffic. No overrun or underrun counts. Rock solid throughout entire rpm range. All above tests were done using the USB serial adapter.

This is why I don't think it is related to CAN communication. But as is usually the case with complex systems, it could be multiple issues.

In theory I could run the engine this way (batch mode) but it would require re-tuning the VE table, and I really don't want to give up all the nice features that come with sequential injection.

Regards,
Dave

[mill383]

Any update on this?

Dave

[jsmcortina]

I'm going to be continuing my investigations on what is happening to cause congestion on the CAN network and the passthrough problems.

I've discussed this with Phil and believe that there are some changes in TunerStudio that would improve the user experience. Hopefully Phil can comment further.

James

[jsmcortina]

I just put out a new MS3 alpha release that I believe has greatly improved CAN passthrough.

There have been some changes in the latest beta TunerStudio version that should make it less sensitive to any overruns.

James