DCC++ Update Project 2020

Ya I'm not really big on trying to update old projects that may have been abandoned as that is the current boat we are in. I mean I can read understand and modify but the time it will take to do that is better spent perfecting the launcher as it stands. If we use Mono however we can potentially go cross platform but at this point it's not worth it due to the fact that if someone is using Linux already they are probably inclined enough to get things done without the installer. As for Mac that is a challenge within itself as Mac Is makes things difficult to begin with and will require a Mac for testing. The closest I can come to that would be testing via Hackintosh but I haven't done that in so long it may prove to be very difficult.

Sent from my Pixel 4 using Tapatalk

 

Do you have an outline for what you are doing? I suppose I can look at the text versions of the files. In particular are you renaming and converting the DCC-EX PlatformIO version or using 2 different methods to compile and upload each? We will probably have a .INO version, but basically you take the files in the src folder of the PlatformIO version, rename DCCpp.cpp to .ino and the remaining .cpp and .h files make the sketch. So it is exactly the same as compiling classic. A user could just copy those files to the Arduino IDE and everything will work. I know it compiles, but I don't remember if I uploaded that version to test or not.

As for VS. I *could* just uninstall VS2012, but I have the full professional version. I am not sure what I would lose going to the "free" version of a later release. Maybe nothing since I just write sample programs in it now, nothing core to my business. I wonder if I can get it to work in VS2012? It may not be that you use the new core, but 2017 and above use the new core format in the .csproj file. So I may not be able to figure out how to edit it to be able to play with the files. I do what the error messages tell me to do and it still gives the same message.

I can "open folder" in VSCode, but can't debug. I can block the popup, but is says I can't use .NET Core debugging without that SDK. Maybe I don't need that for your code if you are only using the 4.8 Framework.

 

I just looked at your code. I can see the gist of what you are doing. If renaming a file is all we need to do. Would using the Arduino compiler for both Classic and EX be simpler? Or is it better to get PlatformIO working? I hear you about Mono. It's tough if we want a one-click installer for multiple platforms. And as we keep reminding ourselves, simpler is better. Whatever works for the installer is good. We don't need to support all the ways that can be compiled. If we need to change it to work on another framework at some point fine. The installer is just a tool. Once it works, there will be no changing it unless we change something about the flow from folders, to build, to upload to the Aruduino

 

You should be able to install VS2019 along side 2012 without any issues or interference. It will also allow you to you compile stuff from 2012 as well and upgrade projects to 2019 if you choose.

Well I can try that since the compile code using Arduino SDK works very simply we can use that to perform compile and it would be easier then i would only need to download Arduino and not worry about Python at all. My issue is getting python working, after reading some documentation in order to get what we need working for PlatformIO so i can just use the console commands i have to install python with path enabled along with running the platformio script i am already downloading. The issue states that the embedded version of python available via zip file cannot actually be used with pip which is why i canno use that version. Either i need to install python directly or like you said rename the cpp file to .ino and hope it compiles XD i think i iwll have to try that on its own.

 

Yes, I can confirm this, too.

We could possibly fork the ArduinoSketchUploader (project site for the ArduinoUploader NuGet package). There is an outstanding pull request (from August 2019) that is supposed to update the project for .NET Standard, so the more tedious work might actually already be done.

The source branch for that pull request is here, so it might be possible to just fork that into DCC-EX and move forward with that without too much additional effort (or—in this particular case—perhaps even as a submodule, and then reference that project directly via a project reference instead of a NuGet package reference.)

I'd be hesitant to suggest targeting Mono, with the way .NET Core is going to be the preferred .NET platform for cross-platform scenarios moving forward.

 

I really do understand what you are saying but as for cross-platform the issue comes into play how do i detect serial ports and do they work properly in Linux and Mac. I can test Linux on my laptop but also i am not sure about all the other things i am using. Me personally i haven't really used .Net Core and its a lil daunting as i have been using framework for so long and love how it works. Yes i know Mono has its issues but Core is also very limited from what i have seen as far as Windows API. We could potentially branch it and try it out but im not sure how that will actually work.

 

In looking at the diff for pull request, there do not appear to be any API changes to ArduinoUploader, and the ArduinoSketchUploader app has only superficial changes proposed to it in main(). Aside from some updated references, the rest is largely project configuration changes.

In a Framework/Core discussion, one good thing is that the API is largely the same across the two. Both .NET Framework and .NET Core can reference assemblies targeting .NET Standard.

You might hear a lot about .NET Standard 2.0 in particular, and that is because .NET Standard 2.0 was when .NET Standard really started to break away from PCL (Portable Class Library) and the API surface of .NET Standard was substantially increased to achieve better API parity with .NET Framework. Thus, if there is code that is not UI-based or not in some of the platform-specific portions of the .NET Framework API, it can be possible to "upgrade" to .NET Standard merely by updating the project file.

.NET 5 Preview 1 was actually released earlier today. Part of the announcement notes, "A later preview will include WPF and Windows Forms." The .NET Framework 4 is supposed to continue to be supported for a while, as it continues to offer Windows-specific capabilities that are not supported by .NET Core. How much of a change there is from .NET Framework 4 to .NET 5 will depend in part on what type of work one does. I was a .NET Compact Framework developer back in the day, so I know what you mean when roadmaps change....


I don't know how strong the push/demand is for a cross-platform Installer for DCC-EX right now. If it is an absolute must-have, it possibly could be done at the present, but if there is opportunity to instead focus on some of the BaseStation work right now, a lot might work out for some of these more advanced Installer scenarios over the remainder of this year. (.NET 5, based on .NET Core, is slated for release by the end of this calendar year.) In the interim, there perhaps might be enough to focus on with BaseStation, so we don't get too far ahead of ourselves…

 

New stuff:

Could use help just looking at classic stuff I want to pull in so we can call that a release. They are the changes we were working on for NMRA compatibility that I merged into EX. Without experimenting we may not know for certain, but look at the changes to readCV and writeCV... in this PR. Search on "fnd" for particular areas where I commented out the old code and inserted new code for a quick comparison inline instead of looking at the diff:

https://github.com/DCC-EX/BaseStation-Classic/pull/3

Working on motor board support and dealing with current in milliamps in addition to the raw pin reading and knowing the max current capability of the board and short trigger current setting. This is in a new branch:

https://github.com/DCC-EX/BaseStation/tree/frightrisk-current-mod

 

Really nice work. I gave it the once over and once the people who actually know what they are talking about look at it I'm eager to test.

I would say in addition to the current thresholds by board we should also put the ACK_SAMPLE_THRESHOLD in PacketRegister.h in there as well. I know for the BTS that number has to be down to around 5-10 to work in most cases though one user went to 70. Probably worth more experimentation but I know thats been an issue on these high power boards so if we want to leave them all at 30 for now I'm fine but I would put that in the motor board definitions than global.

See here https://www.trainboard.com/highball/index.php?threads/is-dcc-as-a-programmer-sensitive.107012/page-2

This is honestly probably the biggest knock on DCC++, the ability to read/write consistently. I thinkif we coul create a testing protocol and have several people run the tests and record results we might be able to crack it and that would be a huge step forward. SPROGs and others seem tohandle so I don't think anything inherent in Arduino the problem. Maybe simply the current sense slop in the motor shields??? Anyway I think work trying to get after

 

I am putting Dex's installer onto my UNO [with the help of Sumner's guide] - the process seems to be stuck [75 minutes] at "Getting Platform IO". Is it a long process? R-

 

Use classic EX is not working atm

Sent from my Pixel 4 using Tapatalk

 

I followed this link from your earlier post..

... can you point me to the working version? R-

 

That is the working version where it says BaseStation select Base station classic

Sent from my Pixel 4 using Tapatalk

 

Right - got it. I didn't spot that the drop-down version had altered in Sumners screenshot, which I have now altered to Classic on my machine. However, I have not uploaded successfully and am being directed to the view the upload.log from where I got this. R-

Message: Could not find file 'C:\Users\RogerB\Downloads\BaseStation-Installer.Alpha.1.1(1)\BaseStationClassic\Build\DCCpp.ino.hex'.
StackTrace: at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.StreamReader..ctor(String path, Encoding encoding, Boolean detectEncodingFromByteOrderMarks, Int32 bufferSize, Boolean checkHost)
at System.IO.StreamReader..ctor(String path, Encoding encoding)
at System.IO.File.InternalReadAllLines(String path, Encoding encoding)
at System.IO.File.ReadAllLines(String path)
at ArduinoUploader.ArduinoSketchUploader.UploadSketch()
at BaseStationInstaller.ViewModels.MainWindowViewModel.CompileSketch()

 

It appears that it didn't build rename the BaseStation installer to have less characters. That should hopefully fix the issue

Sent from my Pixel 4 using Tapatalk

 

Just quoting part of his, but it is is all very relevant. Great idea about the _ACK values. I am even thinking of making them run-time configurable. That involves some issues though. I've had so many ideas, but some require hardware and I would like to avoid that. How many would really want to use the I2C display? Or something that makes a sound? Or an led that blinks? If we have configurable settings, you really have to have end user feedback.

And speaking of feedback, does anyone know why the standard for CV change acknowledgment is a current pulse?? I get that it makes a decoder more expensive to have a transmitter in it as well as a receiver. Maybe that is the biggest reason. Why is this not bi-directional data? Why don't decoders send an error code packet (zero for good and a number corresponding to what it thinks went wrong for an error)? Or why not one or two rings of the locos bell and/or light (need accommodation for sight/hearing impaired folks). Even if decoders didn't do this, DCC++ could do all these things to give an indication of whether a setting "took" or not.

Trying to read the NMRA docs seems pretty convoluted. There is a "basic" ACK mechanism which is simply:

"providing an increased load (positive-delta)on the programming track of at least 60 mA for 6 ms +/-1 ms. It is permissible to provide this increased load by applying power to the motor or other similar device controlled by the Digital Decoder".

With most decoders, we see this as a slight turn of the drive mechanism. Not very high tech. However a 60mA change is easy to detect.

But there is an "advanced" method. The docs refer to sections 9.3.1 and 9.3.2. But if you go there, 9.3.1 is deprecated and it looks like Lenz submitted their Railcom bi-directional spec in 2012 to the NMRA that is rolled into still unfinished documentation. According to THIS, it is an "NMRA standard". Do other decoder manufacturers send data this way? But that still gives us the problem of decoding current pulses They use less than 6ma as a 1 and greater than 10ma as a 0. Backwards to me, and that requires pretty accurate current sensing. And why when we use a amplitude (voltage) PWM modulated signal for DCC would we use a current modulated signal to send data back???

 

Tried removing "installer" from the file name [this in the Downloads folder - is that where I should be?] and upload failed again. Installer closed and no update log this time. I'm stumped. R-

 

In short, a decoder can't send a message back to the command station the same way it receives messages. @Atani or others could likely go into deeper detail and/or correct/clarify, but a DCC command station essentially "communicates" to decoders by changing the polarity of the electric current powering the track. How the polarity is changed determined whether a bit is interpreted as a '0' or a '1' (details are here); other timing considerations also exist, such as cutouts for RailCom.

There are some high-level conceptual similarities between CV acknowledgement and RailCom (bi-directional communication), so here is a quote from the NMRA RailCom spec:

Even though DCC-EX might not support RailCom itself, it should provide for the appropriate cutouts so that other (3rd party) RailCom-capable components could be used if desired.

Edit: example of an add-on RailCom detector

 

Without seeing it it's hard to help. The key is making sure the path is not super long and that it downloaded the source code. And don't worry others had trouble too I will be working on an installer as well.

Sent from my Pixel 4 using Tapatalk

 

Can you give the path to the folder where the installer has been extracted to?

I had problems at first as Dex mentioned due to the fact the path to where the folder was with the installer in it was too long and the installer program couldn't handle it...


Once I made a folder OS(C) > DCC it worked (compiled) fine,

Sumner