<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Michael,<br>
<br>
Linking the several parts to this thread... With the clarity of a
new day, I'm being a bit more methodical, changing one thing at a
time. TL:DR question: What is Canopen actively doing in a system
without the Twizzy even present?<br>
<br>
Continuing on my issue isolation work from last night, it appears
the whole 12v / modem thing might be irrelevant. I've reproduced
the "partial hang", where the OBDWiz dongle gets part way through
the connect sequence before CAN3 hangs. Metrics show 5 frames
received, 7 transmitted. One frame Rx overflow. Error status = 0x
2040. If I stop and restart obdii ecu, I can repeat the hang by
restarting the connect in OBDWiz.<br>
<br>
The previous build was able to start OBDWiz and it ran all night
with no issues. The only difference between this build and the
previous one is that I included Canopen in it. <b>So, first
issue: Why would including Canopen make a difference?</b> I
don't have any reference to Canopen in my config, and the Twizzy
vehicle module is not included in the build (I've got a Tesla
Roadster). The OBDWiz is on CAN3; CAN2 is unconnected. The module
is on my desk, so nothing on CAN1, either.<br>
<br>
The system.start script is as follows:<br>
<blockquote>enable ******<br>
obdii ecu start can3<br>
power ext12v on<br>
wifi mode client<br>
# power simcom on<br>
vehicle module TR<br>
server v2 start<br>
</blockquote>
Note the modem enable is commented out, so the need for 12v power is
shown to be irrelevant. Wifi connectivity is effectively disabled
because the only configured network is hidden, so it doesn't
auto-connect. <br>
<br>
<b>Second issue: If I remove Canopen and change the wifi hotspot to
be not hidden, CAN3 hangs at the point where Wifi auto-connects.
</b>As before, there appears to be an Rx overflow, but this time if
I stop and restart obdii, everything connects and runs properly.
Wifi disconnecting doesn't affect the CAN bus, but when it
reconnects, the hang repeats.<br>
<br>
I've verified with can trace that the frames truly aren't being
received, so it's not the obd2ecu process that's hung. Obd2ecu
continues to process other commands normally (e.g. obdii ecu list).<br>
<br>
So, summarizing, I believe there are two issues here. First, the
CAN2/3 driver needs some work in handling receive overflows. In
theory, the CAN devices should be resilient enough to withstand the
loss of a frame or two, and indeed, I see OBDwiz retrying the
connect (as monitored by Wireshark via a CAN splitter cable).
Second, Canopen is getting in the way, even when it is not being
used. If I understand the ESP architecture, all CAN recipients get
all CAN frames from all (or both?) CAN busses, and ignore the ones
they don't need. I'm guessing this filtering code in Canopen is
taking too long to be transparent.<br>
<br>
Greg<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">Michael Balzer wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c492e7ad-2616-13b8-0565-11adacd8bbd7@expeedo.de">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">Mark,<br>
<br>
the Twizy implementation currently depends largely on the
CANopen framework. It may be possible to build a -very-
restricted version without, but the result would not be used by
any Twizy driver.<br>
<br>
The CANopen framework is also a general toolkit to discover and
talk to CANopen devices, see my intro at:<br>
<br>
<a class="moz-txt-link-freetext"
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master/vehicle/OVMS.V3/components/canopen/doc/Howto-detect-CANopen-nodes.txt"
moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master/vehicle/OVMS.V3/components/canopen/doc/Howto-detect-CANopen-nodes.txt</a><br>
<br>
The RAM usage of the manager module, while not having started a
bus instance, is 24 bytes for the module state plus command
registry. Command registry follows the approach of the CAN
framework to do the interface selection as a command level. So
the CANopen command registry entries consist of 2 + 3 * 13 = 41
commands.<br>
<br>
The same command registry overhead applies to all optional
components, i.e. OBD2ECU and REtools. Maybe a better solution is
to make all these components loadable like the vehicles. I saw
you subclassed RE from pcp, was this meant to support the
dynamic loading/init by means of the power control command, or
is there another plan on this?<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
Am 08.01.2018 um 01:04 schrieb Mark Webb-Johnson:<br>
</div>
<blockquote type="cite"
cite="mid:507CD09E-3370-47DD-A726-51FFB17BE3B6@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<div class=""><br class="">
</div>
<div class="">With renault twizy and canopen enabled:</div>
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class="">
<div class="">
<div class="">OVMS > module memory</div>
<div class="">============================</div>
<div class="">Free 8-bit 78744/243064, 32-bit 29116/55900,
blocks dumped = 0</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">With renault twizy and canopen disabled:</div>
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class="">
<div class="">
<div class="">OVMS > module memory</div>
<div class="">============================</div>
<div class="">Free 8-bit 84928/243096, 32-bit 29720/56504,
blocks dumped = 0</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">I can’t compile with canopen disabled and renault
twizy enabled.</div>
<div class=""><br class="">
</div>
<div class="">Not sure where the difference is, but it would be
preferrable if these optional components didn’t consume any
ram unless explicitly loaded. Using the class object model,
and member variables, should make that relatively simple.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.<br>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="144">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
</body>
</html>