CAN-Do: Usage Problems

If you have Problems when using CAN-Do, please see the "CAN-Do: User Manual" thread to see if the help you need is there.

My CAN-Do program might have bugs, or unintended features, overflows, etc. so ...
Please report/describe them here.
Be sure to include the CAN-Do version number, and your OS type.

----------
Reported Problems:
1. Some Run Error when trying to "Monitor Messages" (while Logging):

A: That function has not yet been debugged. For now, just do not use it.

2. Strange errors, some garbage data, data coming in slowly.

A: Most likely your RS232-to-USB adapter is not GOOD enough. See the $25 GOOD one I tested recently, which has the FTDI chip. Some adapters will appear to work occasionally. Data from the EV bus should come in at about 200 per second, and from the Car-CAN bus even faster.

3.

Past Problems:

Install Problems:

Miscellaneous Warnings:

1. Up to version 1.5.3, CAN-Do can hold only about 20 million messages, which should be enough for about 20-hours of Logging.

2.

garygid said:

----------
Reported Problems:
1. Some Run Error when trying to "Monitor Messages" (while Logging):

That function has not yet been debugged. For now, just do not use it.

Click to expand...

By "Monitor Messages" do you mean running the dashboard while logging messages?
That is what I was trying to do--had just done it successfully (Friday 10/14) on a 15 minute drive of about 6 miles.
Then I started having problems on Saturday logging while having the dashboard running. Was getting Run Time errors.
CAN-Do V1.52
Windows XP
Gigaware USB/RS232 adapter

I am GUESSING that your PC is not (or is not configured to be) fast enough to handle the dashboard display and the RS232 communication at the same time?

If the Logging works well without the Dashboard Display ON, then save that Log to a file.

If CAN-Do has no errors while Reading the Log file, try Reading again, with Show Dashboard checked.

Then, if there is no trouble, it is not data-overflows while Displaying, and it is most likely an over-worked CPU.

Let me know what happens.

What is the exact wording of this Run-Time Error?

I'll try it again this weekend or maybe going to work one day. I just thought it was weird to get run time errors because I had just recorded a session with dashboard monitoring on the previous day and it was flawless.

I had the same experience. Worked perfectly at first with monitoring and dash on but now it only works if I leave them off. The poor CPU performance is a reasonable theory. I am running on a tiny HP netbook (runs for hours on the battery and easy to toss in the pasanger seat during logging). And yes, I do get the errors even when plugged in (so not caused by CPU throttling to conserve battery life).

The RS232-to-USB adaptor is another TYPICAL cause of trouble.
A GOOD one is really necessary, it seems.

I'll do logging sessions with/without the dashboard side by side and post the result. Here is an experience that I would have loved to record, as transmitted in an email to a couple friends:
"Speaking of batteries, we had a great experience going over the hills last Sunday with our trusty SOC meter. We went from Yountville to Santa Rosa to visit a community where my company has some solar systems installed. It was 29 miles one way with about 10 miles of mountain roads. At the summit, we were at 74% charge or 209 gids. On the way down, I shifted between D and ECO to maintain speed and control, so at the bottom we had regen’ed up to 223 gids or 79%. The Energy use meter (which banked that charge) didn’t move for about 5 or 6 miles—it was incredible. We must not have been in a favorable “bars” situation as we didn’t grow a bar on the LEAF SOC gauge. Still it was amazing to grow 5% charge coming downhill. Unfortunately I wasn’t able to record it or it would have been very interesting to see."

If one experiences trouble (CAN-Do program abort, run-time error, etc.)
while Logging with the CAN-Do "dashboard" ON, please turn the
dashboard off and see if the problem goes away.

I might have an overflow or other bug in the dashboard code.
Let me know what version of CAN-Do you are using.
I hope to have a newer CAN-Do out soon, and I would like to "fix" any "known" problems.

I usually Log (with no dashboard), Save to a file, then Read the file later (sometimes with the dashboard ON).

Any "clues" you can give me will help. Thanks, Gary

One more clue. It's not just the dashboard. Monitoring messages results in the fail, too. Usually a few minutes after starting to log.

Monitor Messages is a new function that I have not dubugged.
So, do not use it.

However, it is a clue, Thanks.

Is anybody having trouble JUST logging (no dashboard, no Monitoring)?

I tried to reproduce the run time error today. I was unsuccessful, but I had limited time. I ran logging sessions with and without the dashboard running. Both worked perfectly. I suspect one of two things that I had done earlier: Either I did not uncheck the unused Comm ports (AV, Car, and QC) or I had tried to monitor the messages as well. Today, I unchecked all the comm ports and did not monitor messages for both runs.

Dual Core Pentium running Windows XP Professional.
Used CAN-Do 1.52 for message logging.

"Monitor Messages" is not debugged, so do not try to use it.

In CAN-Do version 1.5.8 (that I hope to post tomorrow),
the option is "gone" (until I get it "fixed").

Not really a problem, but a feature request.

I'd like some way to have the Can-Do program automatically start logging as soon as it starts and save to a unique file everytime it stops. Would also need to have a way to save the configuration (i.e. which com port, can bus, etc.) and bypass all the messages when logging is stopped.

The application is I want to keep a dedicated netbook in the glove box that automatiically logs the activity every time the car is turned on. I can make the netbook wake and start the program when external power is detected and issue an Alt-F4 and sleep when power is taken away.

When I can get to making changes to the CAN-Do program again,
I could do the following:

1. Use a "cando.ini" file to contain all the user-settable parms, which I read and use at startup, and write on User Command.

2. Add a "Quiet Mode" checkbox on the First Screen to inhibit all the "function-complete" messages, to allow un-attended operation of CAN-Do.

3. Add an "Auto-Start-Log" checkbox to the First Screen to automatically go to the I/O Control page and begin COM-based Logging when CAN-Do starts.

4. Currently, Logged messages are only held in memory, not automatically written to a file. I did this to better insure no disruptions or delays in handling and time-stamping the incoming CAN-Messages.

So, I need to add an "Auto-Write-Log" (Log File) checkbox option that would open a Log file before Logging starts, and then write blocks of perhaps 1000 (or 10,000?) messages into the open log file.

The problem comes in closing the Log file properly if ALL power is suddenly lost. Of course, losing External power just switches to Battery power in the netbook.

So, are you intending that CAN-Do would get a "Quit" input of some sort from your External-Power monitoring (shut-down) procedure?

We might need to work together on that a bit to get VB6 to recognize your "signal".

5. I will also need to add an "Auto-Name" (the Log file) checkbox that would create an output file name based on the path "remembered" in the "ini" file, and either a sequence number, or the date and time, or both.

-----
Then, would your External Power-On detection actually run the CAN-Do program from scratch?

Actually if the program can just do the operations upon start and exit, I can use the Windows Task Scheduler to invoke CanDo when it detects ac-power. So VB6 doesn't need to detect the ac power signal although that would be a cleaner solution.

Assuming you can use Task Scheduler to invoke CAN-Do when external power is applied ...
what will tell CAN-Do to "stop/close/quit"?

I was not thinking of adding external-power detection to CAN-Do ...
unless that is an easy thing to do.
I just do not know how to check, but that might handle initiating the "quitting" sequence unless you have a better way.

garygid said:

Assuming you can use Task Scheduler to invoke CAN-Do when external power is applied ...
what will tell CAN-Do to "stop/close/quit"?

I was not thinking of adding external-power detection to CAN-Do ...
unless that is an easy thing to do.
I just do not know how to check, but that might handle initiating the "quitting" sequence unless you have a better way.

Click to expand...

The hack way is to schedule a task for every minute and select the "only perform task when AC power is applied" button (and then check to make sure it isn't already running), but I suspect there is a more elegant method using the advanced section under hardware triggers. Will have to research it more...