-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Accessory decoder changes incompatible to previous versions #15
Comments
Hi Franz-Peter,
On 27/02/2018, at 9:27 AM, Franz-Peter ***@***.***> wrote:
Hi Alex,
I detected, that the actual version 1.4.4 is no longer compatible to previous releases regarding the accessory decoder. The callback functions changed, and the old one is no longer available. Now sketches don't work anymore without any error message.
Is this really intended to be so?
Hmmm… This is the downside of using the “weak reference” mechanism as it will silently ignore your call-back function if it’s not got the right signature.
I haven’t released this version of the code to the Arduino IDE Library manager yet as I was hoping for some feedback from several people to make sure I’d not broken something - so I guess you’re providing that now.
The reason I reworked this and dropped support for the two call-backs:
extern void notifyDccAccState( uint16_t Addr, uint16_t BoardAddr, uint8_t OutputAddr, uint8_t State )
extern void notifyDccSigState( uint16_t Addr, uint8_t OutputIndex, uint8_t State)
is that upon further research into “Output Address Mode” I discovered the logic and approach was just plain wrong as I was mixing up "Board Addressing" and "Output Addressing” which upon reflection, makes no sense as you can’t have both at the same time, which is what notifyDccAccState() was kinda portraying.
If you look at the call-backs now you’ll see they either have Board Addressing or Output Addressing but not both as I had before.
I’ve hunted around to see if I can somehow mark the old function as deprecated or generate a warning somehow if you’ve defined a now unsupported call-back in user code, but I’ve not found anything.
The only thing I can think of to do is change the version to 2.x.x and add more text to the library description to draw attention to the fact that support for those two functions has been removed.
I also just realised that I’d not gone back into the examples and changed the call-back to use the new functions.
What do you think is the best thing to do?
Alex Shepherd
|
Hi Alex, I realized this problem of this new version when users of my 'DCC_Zubehoerdecoder' complained that it did not work. This accessory decoder ist designed for users who don't want ( or are not able ) to program a lot. It can be widely customized by only changing some 'const' definitions in a configuration file. The user usually does not have to change the code itself to adapt the decoder to his needs. Some users downloaded the NmraDcc lib directly from github 'master' instead of installing from the library manager. They had no chance to find the reason why it didn't work. I have to change the decoder, so that it works with the new and the old version without having the user to look after the correct version. At least I need a way to distinguish between old and new Version - e.g. by means of a new #define - to create the correct decoder that fits to the installed nmraDcc library. At least you should change the Version to 2.0.0. I think, if only the minor version number changes, no one expects that it might be incompatible to the previous Version. I saw that you already changed the readme, which will help a lot. But this readme isn't seen if you install the lib with the Library manager. A hint in the library.properties 'paragraph' section may be useful, as this text can be seen in the Library manager. Another possibility might be to provide the old functions in parallel and mark them as 'deprecated' and 'only for compatibility reasons' without any further documentation. The nmradcc.h file is now commented very well ( that's a really big improvement ). I don't think that new users of the lib will ever use those old 'undocumented' functions. Finally one question to the new callbacks: You can change between 'Board Adressing' or 'Output Adress Mode' by means of changing CV29. I think the lib itself must distinguish between the two modes only if FLAGS_MY_ADDRESS_ONLY is set. The only difference is how the Decoder address in CV1/CV9 is interpreted. If FLAGS_MY_ADDRESS_ONLY is not set it is up to the user to distinguish between the two adressing modes. The DCC-packet itself is always the same - it's only a matter of interpretation. The old callbacks left it up to the user how to interpret it. I don't think it was really 'wrong'. Or is there something I forgot? |
Hi Alex, That a decoder address of 1 corresponds to an outputaddress of 0 in the DCC packet should be transparent to the sketch. from 'NMRA s-9.2.2_decoder_cvs': In my opinion this means with a decoder address of 1, there should be no difference between the two address modes. But I think these two statements are a bit contradictory. The problem seems to be, that decoder addresses in CV1/9 should start with '1' while the addresses in the DCC packet start with '0'. It does not really fit together. I think Version 1.4.2 wasn't too bad. |
Hi Franz-Peter,
On 1/03/2018, at 11:12 AM, Franz-Peter ***@***.***> wrote:
Hi Alex,
well, the missing warning or error message is definitely a problem of the (weak) attribute. I don't know a solution for this problem either. So we need another solution to warn the programmer about that.
I realized this problem of this new version when users of my 'DCC_Zubehoerdecoder' <https://github.com/MicroBahner/DCC_Zubehoerdecoder> complained that it did not work. This accessory decoder ist designed for users who don't want to ( or are not able ) to program a lot. It can be widely customized by only changing some 'const' definitions in a configuration file. The user usually does not have to change the code itself to adapt the decoder to his needs. Some users downloaded the NmraDcc lib directly from github 'master' instead of installing from the library manager. They had no chance to find the reason why it didn't work.
I have to change the decoder, so that it works with the new and the old version without having the user to look after the correct version. At least I need a way to distinguish between old and new Version - e.g. by means of a new #define - to create the correct decoder that fits to the installed nmraDcc library.
Or may it be a solution to provide the old an new callbacks in parallel? I'm not quite sure about that and will give it some thought - or try it out ;) .
At least you should change the Version to 2.0.0. I think, if only the minor version number changes, no one expects that it might be incompatible to the previous Version. I saw that you already changed the readme, which will help a lot. But this readme isn't seen if you install the lib with the Library manager. A hint in the library.properties 'paragraph' section may be useful, as this text can be seen in the Library manager.
I have added to the library.properties 'paragraph’ but lets go for version 2.0.0 and I’ll make the warning more obvious… ;)
Another possibility might be to provide the old functions in parallel and mark them as 'deprecated' and 'only for compatibility reasons' without any further documentation. The nmradcc.h file is now commented very well ( that's a really big improvement ). I don't think that new users of the lib will ever use those old 'undocumented' functions.
I’ll try this approach as well. I’ll try and put the notifyDccAccState() and notifyDccSigState()
Finally one question to the new callbacks: You can change between 'Board Adressing' or 'Output Adress Mode' by means of changing CV29. I think the lib itself must distinguish between the two modes only if FLAGS_MY_ADDRESS_ONLY is set. The only difference is how the Decoder address in CV1/CV9 is interpreted. If FLAGS_MY_ADDRESS_ONLY is not set it is up to the user to distinguish between the two adressing modes. The DCC-packet itself is always the same - it's only a matter of interpretation. The old callbacks left it up to the user how to interpret it. I don't think it was really 'wrong'. Or is there something I forgot?
That’s probably an error but the NMRA DCC specs are so confusing in this area that its hard to know what is the expected behaviour. I’ll check the logic around FLAGS_MY_ADDRESS_ONLY.
I was trying to eliminate the need for the user to “interpret” anything but maybe I’m not “done” yet… ;)
Alex
|
Hi Alex, So, when I had a closer look to the changes you made and our discussion above, there are some additional questions/ideas I'd like to discuss:
are not the only ones. What if CV29 is changed and the address mode changes ( bit 6 in accessory decoders ore bit 5 in multifunction decoders ). Does the caching really give much benefit?
How about supporting this in the lib? An additional parameter in the init command could define how many addresses are spanned ( if FLAGS_MY_ADDRESS_ONLY is set). I can send my suggestions as a pull request, if you want. But its still work in progress ;-) Franz-Peter |
Hi Franz-Peter,
On 10/04/2018, at 7:54 AM, Franz-Peter ***@***.***> wrote:
Hi Alex,
I made some changes to the lib to make a suggestion regarding the addressing. I also added a define wich contains the version number. This makes it easier for the sketch to call the correct methods.
So, when I had a closer look to the changes you made and our discussion above, there are some additional questions/ideas I'd like to discuss:
You cached the decoder address to make getMyAddress() a little bit faster ( or is there another reason ? ). But it is really worth it? I think it introduces new possible errors. The effective address can change in many ways. I think these:
switch( CV )
{
case CV_ACCESSORY_DECODER_ADDRESS_LSB: // Also same CV for CV_MULTIFUNCTION_PRIMARY_ADDRESS
case CV_ACCESSORY_DECODER_ADDRESS_MSB:
case CV_MULTIFUNCTION_EXTENDED_ADDRESS_MSB:
case CV_MULTIFUNCTION_EXTENDED_ADDRESS_LSB:
DccProcState.myDccAddress = -1; // Assume any CV Write Operation might change the Address
}
are not the only ones. What if CV29 is changed and the address mode changes ( bit 6 in accessory decoders ore bit 5 in multifunction decoders ). Does the caching really give much benefit?
EEPROM access is not immediate and if there is an EEPROM write operation happening then and subsequent EEPROM actions will block (for 1.8ms) which is bad and why I cache this value. Maybe we should cache some more as well but I kinda cache most of CV29 already which is the other important one.
How about we just add CV_29 (and any others you can think of) to the list of CVs that invalidates the address cache? Would that overcome your concerns?
The NMRA papers explicity allow a decoder to span several addresses. in NMRA 9.2.2:
If an accessory decoder supports more than one sequential output the value in CV1 [513] will be the first output in the series
How about supporting this in the lib? An additional parameter in the init command could define how many addresses are spanned ( if FLAGS_MY_ADDRESS_ONLY is set).
Yeah this behaviour is not so well defined - mostly because the NMRA specs are so ambiguous and hard to figure out (at the time I did most of this) really what should happen, so I’m open to suggestions…;)
I imagined a couple of scenarios:
1) Your decoder has a list of sequential addresses, so we could define a start and end or start and length of address group. The latter is probably better.
2) Your decoder has a list of non-sequential addresses, so internally we’d need to compare any incoming addresses to our list to see if we care about it.
Really my thinking around FLAGS_MY_ADDRESS_ONLY was for the NMRA Board Address type logic which was pretty well defined.
However as soon as you go into Signals and non-sequential addressing all the simplicity disappears. It’s not rocket science but deciding how to do something to handle this in an intuitive and generic way hasn’t materialised in my head yet. Hence the reason it is the way it is. As it is you can either use the FLAGS_MY_ADDRESS_ONLY with a Board address or do your own thing checking the Address in the notifyXXX call-back functions.
I can send my suggestions as a pull request, if you want. But its still work in progress ;-)
That would be good. I don’t profess to be the sole source of DCC Decoder wisdom and this is a community right… ;)
HTH
Alex Shepherd
|
Hi Alex
Yes, that is what I did already ;) . I didn't notice, that writing to the EEPROM of course delays reading from the EEPROM too.
I think, that's not possible. The library should not be too restrictive, when interpreting the packets. In the meanwhile I had a closer look at the MOROP papers. These norms are based on the NMRA, but in some points they are enhanced. Unfortunately they are only available in german and french so far ( They are searching for someone to translate to english ).
Yes, and maybe its the better way to leave checking the address to the sketch in all other cases? The more papers you read, the more obscure it seems to be - especially with output addressing. With extended accessory packets obviously there is only output addressing. Unfortunaltely I don't have any equipment that generates such packets. I wonder whether there is an offset in addressing just like the basic packets. Does signal address '1' generate a packet with packet address '0' or packet addres '4' ? If there is no such offset, the output address should be computed different between basic and extended accessory packets. Franz-Peter |
I've committed your PR that restores one of the call-backs I had dropped. I guess to be consistent we should restore the other call as well: I'll leave this open to remind me... |
Hi Alex,
Yes that's true. It doesn't make sense to restore only one of the two. I got it off my mind because I never used that callback. |
Ok yes. I’ll do that.
I’ve had quite a bit of interaction with someone else building a coach lighting decoder and from that I’m thinking of adding another check in the Dcc.init() method to first check the storage of CV 7&8 to see if they are 255 prior to being set which would indicate a fresh or erased chip and trigger the RestoreFactoryDefaults call-back.
What do you think?
Alex
…Sent from my iPad
On 18/04/2018, at 8:40 AM, Franz-Peter ***@***.***> wrote:
Hi Alex,
I guess to be consistent we should restore the other call as well:
Yes that's true. It doesn't make sense to restore only one of the two. I got it off my mind because I never used that callback.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
That is not a good idea, basing resets on pre-supposed EEPROM contents. Use some explicit, non-ambiguous, assumption-less methods.
Also, are all these changes going to change the default accessory decoder addressing method via JMRI? If yes, I would advocate a strenuous no, leave the current mechanism the default. Otherwise you are going to potentially mess up a few thousand decoders coming on line.
Best regards,
Geoff Bunza
Sent from XFINITY Connect App
------ Original Message ------
From: Alex Shepherd
To: mrrwa/NmraDcc
Cc: Subscribed
Sent: April 17, 2018 at 1:50 PM
Subject: Re: [mrrwa/NmraDcc] Accessory decoder changes incompatible to
previous versions (#15)
Ok yes. I’ll do that.
I’ve had quite a bit of interaction with someone else building a coach lighting decoder and from that I’m thinking of adding another check in the Dcc.init() method to first check the storage of CV 7&8 to see if they are 255 prior to being set which would indicate a fresh or erased chip and trigger the RestoreFactoryDefaults call-back.
What do you think?
Alex
Sent from my iPad
On 18/04/2018, at 8:40 AM, ***@***.***>wrote:
Hi Alex,
I guess to be consistent we should restore the other call as well:
Yes that's true. It doesn't make sense to restore only one of the two. I got it off my mind because I never used that callback.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly,view it on GitHub(#15 (comment)), ormute the thread(https://github.com/notifications/unsubscribe-auth/APID0nKgBBmuGeY6h10kxfMDqhtLeVoaks5tplWFgaJpZM4ST32j).
|
Hi Geoff,
On 18/04/2018, at 9:01 AM, Geoff Bunza ***@***.***> wrote:
That is not a good idea, basing resets on pre-supposed EEPROM contents. Use some explicit, non-ambiguous, assumption-less methods.
Hmmm… Ok
The use-case is quite specific, where the two Read-Only CVs CV_VERSION_ID (CV7) = 255 and CV_MANUFACTURER_ID (CV8) = 255 means the EEPROM has been erased and should optionally be reset to the Factory Defaults, if that call-back is defined.
However to not risk breaking existing code, I can make this new proposed behaviour dependant on passing in a new FLAGS_AUTO_FACTORY_DEFAULT option into the Dcc.init() method, that enables the check and optional call to notifyCVResetFactoryDefault() if it is defined and if the 2 CV in EEPROM = 255.
I’ve committed this change in GitHub so you can take a look and comment.
Also, are all these changes going to change the default accessory decoder addressing method via JMRI? If yes, I would advocate a strenuous no, leave the current mechanism the default. Otherwise you are going to potentially mess up a few thousand decoders coming on line.
I expect not, unless it’s actually broken now. I need to double-check the NMRA DCC Specs against the current implementation and run some more test cases through it to be sure.
For now I’ve NOT bumped the released TAG in the Git Repo, so the version of the library that the Arduino IDE Library Manager downloads is still 1.4.2 which has none of these changes, as I’m not sure we are “there yet”…
HTH
Alex Shepherd
|
Hi Alex and Geoff,
I go along with Geoff and would not do too much specific stuff in the lib. Its easy in the Sketch to decide whether the EEPROM has to be initialized or not. But if you make it dependent on a special flag ...
The addressing method should now be the same as in 1.4.2. The main difference is in getMyAddr, as in 1.4.2 this didn't work in OuputMode for adresses greater than 255. I did some tests with JMRI and a dcc++ base station. I didn't see any problems with the addressing method so far. But I found another problem: When using FLAGS_OUTPUT_ADDRESS_MODE and FLAGS_MY_ADDRESS_ONLY together, I never got a match. Obviously it is caused by this code (line 1114):
If the Outputaddress matches, the first if gets false, and then the else ist executed, where the Boardaddress is tested, what always fails if the address is >1. The first if has to be split in two separated ifs to get it working:
Franz-Peter |
Geoff, I have been trying for about a week to send this to this thread. I am new to dcc ++. I purchased a mega and downloaded & successfully compiled the dccpp BaseStation Sketch to it. I successfully got the dccppcontroler working in Processing IDE and connected to the BaseStation although w/o a motor shield I can not do anything with it. I assume that the output is to low a voltage to even connect to the "programming" track although I have not tried yet? I would like to know so many things it is hard to start.
Any help would be much appreciated! Thanks, Erich |
Hi Alex,
I now restored it in my last pull request ;) Franz-Peter |
Thanks for doing this. I’ve not gotten to any of this for several months. I’ll try and get some testing time soon and also ping Geoff Bunga to also test his code.
Alex
…Sent from my iPad
On 21/06/2018, at 3:17 AM, Franz-Peter ***@***.***> wrote:
Hi Alex,
I guess to be consistent we should restore the other call as well:
extern void notifyDccSigState( uint16_t Addr, uint8_t OutputIndex, uint8_t State)
I'll leave this open to remind me...
I now restored it in my last pull request ;)
Franz-Peter
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Hi Alex
that would be fine. I think there are no open issues left, and testing is the most important thing to do now. I tested with a DCC++ commandstation and JMRI. I also enhanced DCC++ a little bit, to create extended accessory packets and accessory ops mode programming packets by means of a serial Terminal. |
Working on this now.
Best regards,
Geoff
On 6/22/2018 2:01 AM, Franz-Peter
wrote:
Hi Alex
I’ll try and get some testing time soon and also ping Geoff
Bunga to also test his code.
that would be fine. I think there are no open issues left, and
testing is the most important thing to do now. I tested with a
DCC++ commandstation and JMRI. I also enhanced DCC++ a little
bit, to create extended accessory packets and accessory ops mode
programming packets by means of a serial Terminal.
The more independent tests, the better it is.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
{"@context":"http://schema.org","@type":"EmailMessage","potentialAction":{"@type":"ViewAction","target":"https://github.com/mrrwa/NmraDcc/issues/15#issuecomment-399374016","url":"https://github.com/mrrwa/NmraDcc/issues/15#issuecomment-399374016","name":"View Issue"},"description":"View this Issue on GitHub","publisher":{"@type":"Organization","name":"GitHub","url":"https://github.com"}}
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/mrrwa/NmraDcc","title":"mrrwa/NmraDcc","subtitle":"GitHub repository","main_image_url":"https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/mrrwa/NmraDcc"}},"updates":{"snippets":[{"icon":"PERSON","message":"@MicroBahner in #15: Hi Alex\r\n\u003e I’ll try and get some testing time soon and also ping Geoff Bunga to also test his code.\r\n\r\nthat would be fine. I think there are no open issues left, and testing is the most important thing to do now. I tested with a DCC++ commandstation and JMRI. I also enhanced DCC++ a little bit, to create extended accessory packets and accessory ops mode programming packets by means of a serial Terminal.\r\nThe more independent tests, the better it is.\r\n"}],"action":{"name":"View Issue","url":"#15 (comment)"}}}
{
"@type": "MessageCard",
"@context": "http://schema.org/extensions",
"hideOriginalBody": "false",
"originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB",
"title": "Re: [mrrwa/NmraDcc] Accessory decoder changes incompatible to previous versions (#15)",
"sections": [
{
"text": "",
"activityTitle": "**Franz-Peter**",
"activityImage": "https://assets-cdn.github.com/images/email/message_cards/avatar.png",
"activitySubtitle": "@MicroBahner",
"facts": [
]
}
],
"potentialAction": [
{
"name": "Add a comment",
"@type": "ActionCard",
"inputs": [
{
"isMultiLine": true,
"@type": "TextInput",
"id": "IssueComment",
"isRequired": false
}
],
"actions": [
{
"name": "Comment",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"IssueComment\",\n\"repositoryFullName\": \"mrrwa/NmraDcc\",\n\"issueId\": 15,\n\"IssueComment\": \"{{IssueComment.value}}\"\n}"
}
]
},
{
"name": "Close issue",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"IssueClose\",\n\"repositoryFullName\": \"mrrwa/NmraDcc\",\n\"issueId\": 15\n}"
},
{
"targets": [
{
"os": "default",
"uri": "#15 (comment)"
}
],
"@type": "OpenUri",
"name": "View on GitHub"
},
{
"name": "Unsubscribe",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\": 307199395\n}"
}
],
"themeColor": "26292E"
}
…--
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;
mso-font-charset:1;
mso-generic-font-family:roman;
mso-font-format:other;
mso-font-pitch:variable;
mso-font-signature:0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;
mso-font-charset:0;
mso-generic-font-family:swiss;
mso-font-pitch:variable;
mso-font-signature:-536859905 -1073732485 9 0 511 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-parent:"";
margin-top:0in;
margin-right:0in;
margin-bottom:10.0pt;
margin-left:0in;
line-height:115%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
mso-themecolor:hyperlink;
text-decoration:underline;
text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-noshow:yes;
mso-style-priority:99;
color:purple;
mso-themecolor:followedhyperlink;
text-decoration:underline;
text-underline:single;}
span.SpellE
{mso-style-name:"";
mso-spl-e:yes;}
.MsoChpDefault
{mso-style-type:export-only;
mso-default-props:yes;
font-size:10.0pt;
mso-ansi-font-size:10.0pt;
mso-bidi-font-size:10.0pt;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;
mso-header-margin:.5in;
mso-footer-margin:.5in;
mso-paper-source:0;}
div.Section1
{page:Section1;}
-->
Geoff Bunza
gbglacier@comcast.net
scalemodelanimation.com
|
Hi,
Here's a quick testing update: It looks like the
timing of the main loop has slowed down
and/or has become variable -- I'm not 100% sure which. It looks
like it is not as consistent as it was in
the last major release since I updated the SMA examples (I'm not
sure how far back that was). The net
effect is that I have had to modify internal parameters to the
decoder set.
I am adding the last major functionality which appeared in the
March 2017 Model Railroad Hobbyist
magazine article, which includes audio and stepper control
variants.
I have already added long addressing for both mobile and accessory
decoder variations for all examples.
I have to write up the release notes and finish the complete set
of hardware configuration tests.
Baseline functionality looks consistently good.
Has anyone done testing on the Teensy 3.2 and/or 3.6? I will
likely use that in a near future project.
Have fun! :-)
Best regards,
Geoff Bunza <--- Note Correct Spelling Please
On 6/22/2018 2:01 AM, Franz-Peter
wrote:
Hi Alex
I’ll try and get some testing time soon and also ping Geoff
Bunga to also test his code.
that would be fine. I think there are no open issues left, and
testing is the most important thing to do now. I tested with a
DCC++ commandstation and JMRI. I also enhanced DCC++ a little
bit, to create extended accessory packets and accessory ops mode
programming packets by means of a serial Terminal.
The more independent tests, the better it is.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
{"@context":"http://schema.org","@type":"EmailMessage","potentialAction":{"@type":"ViewAction","target":"https://github.com/mrrwa/NmraDcc/issues/15#issuecomment-399374016","url":"https://github.com/mrrwa/NmraDcc/issues/15#issuecomment-399374016","name":"View Issue"},"description":"View this Issue on GitHub","publisher":{"@type":"Organization","name":"GitHub","url":"https://github.com"}}
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/mrrwa/NmraDcc","title":"mrrwa/NmraDcc","subtitle":"GitHub repository","main_image_url":"https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/mrrwa/NmraDcc"}},"updates":{"snippets":[{"icon":"PERSON","message":"@MicroBahner in #15: Hi Alex\r\n\u003e I’ll try and get some testing time soon and also ping Geoff Bunga to also test his code.\r\n\r\nthat would be fine. I think there are no open issues left, and testing is the most important thing to do now. I tested with a DCC++ commandstation and JMRI. I also enhanced DCC++ a little bit, to create extended accessory packets and accessory ops mode programming packets by means of a serial Terminal.\r\nThe more independent tests, the better it is.\r\n"}],"action":{"name":"View Issue","url":"#15 (comment)"}}}
{
"@type": "MessageCard",
"@context": "http://schema.org/extensions",
"hideOriginalBody": "false",
"originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB",
"title": "Re: [mrrwa/NmraDcc] Accessory decoder changes incompatible to previous versions (#15)",
"sections": [
{
"text": "",
"activityTitle": "**Franz-Peter**",
"activityImage": "https://assets-cdn.github.com/images/email/message_cards/avatar.png",
"activitySubtitle": "@MicroBahner",
"facts": [
]
}
],
"potentialAction": [
{
"name": "Add a comment",
"@type": "ActionCard",
"inputs": [
{
"isMultiLine": true,
"@type": "TextInput",
"id": "IssueComment",
"isRequired": false
}
],
"actions": [
{
"name": "Comment",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"IssueComment\",\n\"repositoryFullName\": \"mrrwa/NmraDcc\",\n\"issueId\": 15,\n\"IssueComment\": \"{{IssueComment.value}}\"\n}"
}
]
},
{
"name": "Close issue",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"IssueClose\",\n\"repositoryFullName\": \"mrrwa/NmraDcc\",\n\"issueId\": 15\n}"
},
{
"targets": [
{
"os": "default",
"uri": "#15 (comment)"
}
],
"@type": "OpenUri",
"name": "View on GitHub"
},
{
"name": "Unsubscribe",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\": 307199395\n}"
}
],
"themeColor": "26292E"
}
…--
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;
mso-font-charset:1;
mso-generic-font-family:roman;
mso-font-format:other;
mso-font-pitch:variable;
mso-font-signature:0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;
mso-font-charset:0;
mso-generic-font-family:swiss;
mso-font-pitch:variable;
mso-font-signature:-536859905 -1073732485 9 0 511 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-parent:"";
margin-top:0in;
margin-right:0in;
margin-bottom:10.0pt;
margin-left:0in;
line-height:115%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
mso-themecolor:hyperlink;
text-decoration:underline;
text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-noshow:yes;
mso-style-priority:99;
color:purple;
mso-themecolor:followedhyperlink;
text-decoration:underline;
text-underline:single;}
span.SpellE
{mso-style-name:"";
mso-spl-e:yes;}
.MsoChpDefault
{mso-style-type:export-only;
mso-default-props:yes;
font-size:10.0pt;
mso-ansi-font-size:10.0pt;
mso-bidi-font-size:10.0pt;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;
mso-header-margin:.5in;
mso-footer-margin:.5in;
mso-paper-source:0;}
div.Section1
{page:Section1;}
-->
Geoff Bunza
gbglacier@comcast.net
scalemodelanimation.com
|
I've just committed Franz-Peter's changes into the NmraDcc/master branch |
Hi Alex,
I detected, that the actual version 1.4.4 is no longer compatible to previous releases regarding the accessory decoder. The callback functions changed, and the old one is no longer available. Now sketches don't work anymore without any error message.
Is this really intended to be so?
Regards
Franz-Peter
The text was updated successfully, but these errors were encountered: