Loco suddenly stops due to false current overload

[mgagneur]

Hello Harald,

I have been running the latest build for a couple of days and have found the CV reading / writing to be much better. I do that on a short 1 meter programming track using a Mega and arduino shield.

Today I moved the code over to my main layout and started running 1 loco. I do monitor current using the "c" command and it bounced around a bit but averaged about 300. Everything ran fine for a couple of minutes and then the track shutdown due to a <p2 MAIN 3025> over current. That seemed odd so I did it again and sure enough a minute or two later it did it again. I then changed out locos to a generic Bachmann sound value diesel and it did the same thing.

I then loaded your code from about April 1st and ran the same Bachmann loco without issue. Here's the data from the serial monitor.

Thanks for all of the improvements you are making.

Regards,

Marty

[habazut]

I made some changes to the current reading code which was very unsensitive before. Now the code shuts down if either one reading is greater than 2 times the limit or if several readings (logarthmically smoothed) are over the limit. All the numbers are now in milliampere. For the arduinoshield I configured a limit of 1500. So <p2 MAIN 3025> means you had a single reading that was > 3A. That's odd because if the motor shield's spec is to give a voltage from 0 to 5V to the sensing pin which corrensponds 0 to 3031mA. So this was quite near max. I have no idea if the shields can give false readings. I don't know if this is too trigger happy. If you feel brave you can change the code in CurrentMonitor.cpp where it says if(c > 2*currentlimit || current>currentlimit) and change it to if (current > currentlimit).

Regards, Harald.

[mgagneur]

Hello Harald,

I have ran every version of DCC++ out there for years and this is the first time this has ever occurred. Simply loading an earlier version of your code mitigates the issue. It doesn't seem like it's a shield issue to me but to reduce the probability I have a shield I use on my programming track that I can and try. I will investigate and let you know what I find.

Regards,

Marty

On Wed, Apr 15, 2020 at 8:57 PM habazut notifications@github.com wrote:

I made some changes to the current reading code which was very unsensitive before. Now the code shuts down if either one reading is greater than 2 times the limit or if several readings (logarthmically smoothed) are over the limit. All the numbers are now in milliampere. For the arduinoshield I configured a limit of 1500. So <p2 MAIN 3025> means you had a single reading that was > 3A. That's odd because if the motor shield's spec is to give a voltage from 0 to 5V to the sensing pin which corrensponds 0 to 3031mA. So this was quite near max. I have no idea if the shields can give false readings. I don't know if this is too trigger happy. If you feel brave you can change the code in CurrentMonitor.cpp where it says if(c > 2*currentlimit || current>currentlimit) and change it to if (current > currentlimit).

Regards, Harald.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/habazut/dcc-ardu/issues/2#issuecomment-614353080, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACO5MOWM7HRXJG6EFYOUH6DRMZJXJANCNFSM4MI7MFSQ .

[habazut]

Could you test the following on your layout: I made a modification to the code which is in the branch overcurrenttest https://github.com/habazut/dcc-ardu/tree/overcurrenttest you can either pull down the whole code or just add lines 37-39 of https://github.com/habazut/dcc-ardu/blob/overcurrenttest/DCCpp_Uno/CurrentMonitor.cpp This will report but not shutdown when the short overcurrent situations appear. I'm curious how often that happens. It will still shutdown on "longer" (approx > 20ms) overcurents.

Regards, Harald.

[mgagneur]

Hello Harald,

Sure, I'm happy to do that. No problem.

I did have an idea I'm going to test as well. I have a hypothesis that your code is telling the truth when it reports a sudden short over current. At the same time this may be normal behavior. My layout has several Digitrax AR1 auto reversers that by design function when a loco shorts the track from one section to another. I think the AR1 uses a relay and is not terribly fast. I'm guessing your new code is a lot quicker and from time to time catches the short that happens when the AR1 switches.

Regards,

On Thu, Apr 16, 2020 at 2:55 AM habazut notifications@github.com wrote:

Could you test the following on your layout: I made a modification to the code which is in the branch overcurrenttest https://github.com/habazut/dcc-ardu/tree/overcurrenttest you can either pull down the whole code or just add lines 37-39 of

https://github.com/habazut/dcc-ardu/blob/overcurrenttest/DCCpp_Uno/CurrentMonitor.cpp This will report but not shutdown when the short overcurrent situations appear. I'm curious how often that happens. It will still shutdown on "longer" (approx > 20ms) overcurents.

Regards, Harald.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/habazut/dcc-ardu/issues/2#issuecomment-614451236, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACO5MOVXVBS4SM4JWP4JFDTRM2TV5ANCNFSM4MI7MFSQ .

[mgagneur]

Hello Harald,

I think my idea of what's causing the issue is correct. I will implement the code changes you suggested this evening, but meanwhile being stuck working from home gave me a chance to turn the layout on and run a single loco at very low speed. I turned it on and let it go returning to see if it had stopped periodically. It did stop by turning off track power several times. Each time the loco was at a track break separating two zones where an AR1 needed to sense a short and then quickly swap polarity. It was not the same AR1 each time. Sometimes I could hear the relay click and and the loco continued perfectly happy other times it would touch the track break and stop dead.

It does explain why other DCC++ versions are tolerant.

I will implement your changes and report back.

Thanks for your efforts.

Regards,

Marty

On Thu, Apr 16, 2020 at 6:55 AM Marty Gagneur mgagneur123@gmail.com wrote:

Hello Harald,

Sure, I'm happy to do that. No problem.

I did have an idea I'm going to test as well. I have a hypothesis that your code is telling the truth when it reports a sudden short over current. At the same time this may be normal behavior. My layout has several Digitrax AR1 auto reversers that by design function when a loco shorts the track from one section to another. I think the AR1 uses a relay and is not terribly fast. I'm guessing your new code is a lot quicker and from time to time catches the short that happens when the AR1 switches.

Regards,

On Thu, Apr 16, 2020 at 2:55 AM habazut notifications@github.com wrote:

Could you test the following on your layout: I made a modification to the code which is in the branch overcurrenttest https://github.com/habazut/dcc-ardu/tree/overcurrenttest you can either pull down the whole code or just add lines 37-39 of

https://github.com/habazut/dcc-ardu/blob/overcurrenttest/DCCpp_Uno/CurrentMonitor.cpp This will report but not shutdown when the short overcurrent situations appear. I'm curious how often that happens. It will still shutdown on "longer" (approx > 20ms) overcurents.

Regards, Harald.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/habazut/dcc-ardu/issues/2#issuecomment-614451236, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACO5MOVXVBS4SM4JWP4JFDTRM2TV5ANCNFSM4MI7MFSQ .

[habazut]

When you do the change and report back, an interresting thing to know would be what and how many of the <p2 MAIN 3xxx> messages you get at every track break until the AR1 swiches over. I have 2 Lenz units doing the autoreversing on my layout and these are the old ones with the relais but I have not seen this problem yet. It could be that my power supply that drives the Arduino even if rated at 7A is not that fast to ramp up the current. It might as well has to do something with how long and of what gauge your cables are compared to mine.

Another thing to implement woud be auto-power (say 10s) n after some period so one does not do it manually. Probably configurable.

That might help me to adjust it to be as tolerant as needed but as sensitive as possible.

Harald.

[mgagneur]

Hello Harald,

I hope you are doing well.

Well, I have a result but it's probably not what you were expecting :)

test 1 baseline: Run a single generic Bachmann loco with a Sound Value decoder using the code I downloaded from about April 1st. Ran with no issue for about 15 minutes. Stopped test.

test 2: Run a single generic Bachmann loco with a Sound Value decoder using the code I downloaded from about April 16 with the test code - if (current>currentlimit){ digitalWrite(signalpin,LOW); // disable pin in question } I was thinking the loco would run without issue and send a message <p2 MAIN XXXX> when it saw a quick current spike. It may send several messages as well. Only when it detected a true short would it remove power.

I forgot to mention that I have two types if auto reversers. I have several AR1s and I also use use Tam Valley Depot Frog Juicers to power turnout frogs. I have some smaller locos that would stall on turnouts and after adding the Frog Juicer they all ran thru the turnouts with no issue.

During this test I never saw the message where the loco would continue to run.

I did have several occurrences where the loco would contact an AR1 track break and stop turning off power. A <p2 MAIN 3022> type message was sent. I observed one occurrence where the loco touched a turnout Frog and stopped turning off power. A <p2 MAIN 3022> type message was sent.

test 3. recheck baseline. I quickly reloaded the April 1st code and ran with no issue for about 15 minutes. Stopped test.

Hope this helps,

Regards,

Marty

On Thu, Apr 16, 2020 at 2:45 PM habazut notifications@github.com wrote:

When you do the change and report back, an interresting thing to know would be what and how many of the <p2 MAIN 3xxx> messages you get at every track break until the AR1 swiches over. I have 2 Lenz units doing the autoreversing on my layout and these are the old ones with the relais but I have not seen this problem yet. It could be that my power supply that drives the Arduino even if rated at 7A is not that fast to ramp up the current. It might as well has to do something with how long and of what gauge your cables are compared to mine.

Another thing to implement woud be auto-power (say 10s) n after some period so one does not do it manually. Probably configurable.

That might help me to adjust it to be as tolerant as needed but as sensitive as possible.

Harald.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/habazut/dcc-ardu/issues/2#issuecomment-614830346, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACO5MOWL2SCC6VDMRQ446M3RM5G4HANCNFSM4MI7MFSQ .

[mgagneur]

Hello Harald,

One other piece of data.

My main layout uses an arduino UNO and arduino shield (no clones etc.) My programming track uses arduino MEGA and arduino shield.

Regards,

On Fri, Apr 17, 2020 at 9:26 AM Marty Gagneur mgagneur123@gmail.com wrote:

Hello Harald,

I hope you are doing well.

Well, I have a result but it's probably not what you were expecting :)

test 1 baseline: Run a single generic Bachmann loco with a Sound Value decoder using the code I downloaded from about April 1st. Ran with no issue for about 15 minutes. Stopped test.

test 2: Run a single generic Bachmann loco with a Sound Value decoder using the code I downloaded from about April 16 with the test code - if (current>currentlimit){ digitalWrite(signalpin,LOW); // disable pin in question } I was thinking the loco would run without issue and send a message <p2 MAIN XXXX> when it saw a quick current spike. It may send several messages as well. Only when it detected a true short would it remove power.

I forgot to mention that I have two types if auto reversers. I have several AR1s and I also use use Tam Valley Depot Frog Juicers to power turnout frogs. I have some smaller locos that would stall on turnouts and after adding the Frog Juicer they all ran thru the turnouts with no issue.

During this test I never saw the message where the loco would continue to run.

I did have several occurrences where the loco would contact an AR1 track break and stop turning off power. A <p2 MAIN 3022> type message was sent. I observed one occurrence where the loco touched a turnout Frog and stopped turning off power. A <p2 MAIN 3022> type message was sent.

test 3. recheck baseline. I quickly reloaded the April 1st code and ran with no issue for about 15 minutes. Stopped test.

Hope this helps,

Regards,

Marty

On Thu, Apr 16, 2020 at 2:45 PM habazut notifications@github.com wrote:

When you do the change and report back, an interresting thing to know would be what and how many of the <p2 MAIN 3xxx> messages you get at every track break until the AR1 swiches over. I have 2 Lenz units doing the autoreversing on my layout and these are the old ones with the relais but I have not seen this problem yet. It could be that my power supply that drives the Arduino even if rated at 7A is not that fast to ramp up the current. It might as well has to do something with how long and of what gauge your cables are compared to mine.

Another thing to implement woud be auto-power (say 10s) n after some period so one does not do it manually. Probably configurable.

That might help me to adjust it to be as tolerant as needed but as sensitive as possible.

Harald.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/habazut/dcc-ardu/issues/2#issuecomment-614830346, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACO5MOWL2SCC6VDMRQ446M3RM5G4HANCNFSM4MI7MFSQ .

[habazut]

Please test with new over current code from now on the branch called overcurrenttest. It will always first complain 10 times with detailed current readings until it shuts off the power. https://github.com/habazut/dcc-ardu/archive/overcurrenttest.zip

Example output:

<p2 MAIN Errors: 1 MomCurrent: 2169 SmoothCurrent: 1625><p2 MAIN Errors: 2 MomCurrent: 2169 SmoothCurrent: 1834><p2 MAIN Errors: 3 MomCurrent: 2172 SmoothCurrent: 1836><p2 MAIN Errors: 4 MomCurrent: 2172 SmoothCurrent: 1836><p2 MAIN Errors: 5 MomCurrent: 2163 SmoothCurrent: 1831><p2 MAIN Errors: 6 MomCurrent: 2169 SmoothCurrent: 1834><p2 MAIN Errors: 7 MomCurrent: 2169 SmoothCurrent: 1834><p2 MAIN Errors: 8 MomCurrent: 2169 SmoothCurrent: 1834><p2 MAIN Errors: 9 MomCurrent: 2169 SmoothCurrent: 1834><p2 MAIN Errors: 10 MomCurrent: 2169 SmoothCurrent: 1834>

Harald.

[mgagneur]

Hello Harald,

Loaded the new sketch and ran for a good while (15- 20 minutes). The loco never stopped. During that time I recorded 7 occurrences of the current spike at various places. Each occurrence looked similar to this: <p2 MAIN Errors: 1 MomCurrent: 3022 SmoothCurrent: 1643> At no time was there ever more than one error message.

Regards,

On Fri, Apr 17, 2020 at 9:59 AM habazut notifications@github.com wrote:

Please test with new over current code from now on the branch called overcurrenttest. It will always first complain 10 times with detailed current readings until it shuts off the power. https://github.com/habazut/dcc-ardu/archive/overcurrenttest.zip

Example output: [code] <p2 MAIN Errors: 1 MomCurrent: 2169 SmoothCurrent: 1625><p2 MAIN Errors: 2 MomCurrent: 2169 SmoothCurrent: 1834><p2 MAIN Errors: 3 MomCurrent: 2172 SmoothCurrent: 1836><p2 MAIN Errors: 4 MomCurrent: 2172 SmoothCurrent: 1836><p2 MAIN Errors: 5 MomCurrent: 2163 SmoothCurrent: 1831><p2 MAIN Errors: 6 MomCurrent: 2169 SmoothCurrent: 1834><p2 MAIN Errors: 7 MomCurrent: 2169 SmoothCurrent: 1834><p2 MAIN Errors: 8 MomCurrent: 2169 SmoothCurrent: 1834><p2 MAIN Errors: 9 MomCurrent: 2169 SmoothCurrent: 1834><p2 MAIN Errors: 10 MomCurrent: 2169 SmoothCurrent: 1834> [/code]

Harald.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/habazut/dcc-ardu/issues/2#issuecomment-615259932, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACO5MOXM3BJJH3B42WZUYO3RNBOC7ANCNFSM4MI7MFSQ .

[habazut]

Sounds reasonable. If you never have more than one occurence of that message, you can change the errors>9 in Currentmonitor.cpp to errors>2 and you will have a faster shutdown if a real short happens. In the meantime I'll think how to write the code nicer and without debug messages.

Regards, Harald.