If we decide to address over DCC++ then we need to address decoders (ie such as Geoff Bunza's SMA20 17-function decoder) from the Nextion display. These should be entered in the Nextion display just like mobile loc decoders, and subsequently translate speed, light, sound for that loco in commands from Nextion to DCC++ just as it is done now in your Nextion project. Hence per turnout: decoder address + turnout address ( 1 bit (if latching) or 2 bits (if pulsed, per turnout). C/MRI: this is a bus different to DCC++, so no option here. Just to make sure: if a single pulse is used, then the hardware must know if this is to close or to open a turnout, hence 2 bits are needed. If latching, 1 bit will decide whether the turnout is open or close. This is a major implication for software because it will determine what message needs to be sent by Nextion. Right? It is a bit like website design in a confined space; "done" refers to the head page, branch from there.
Hi again Erik, Firstly, I must apologize:-( I've been getting ahead of myself and losing focus of the issue at hand. I think my mind has been overcrowded with the workings of the other project I'm working on and the challenges I'm having there I made a bit of a breakthrough earlier today with my other project which allowed me to look with a little more clarity at the Nextion implementation. The first and most important reminder was that the Nextion based throttle, like most other throttles, is a device to supply commands to a Command Station in a format that Command Station understands, to perform certain tasks - duh. This means the throttle is compelled to submit information to the Command Station using the Command Set understood by that particular Command Station. It has nothing to do with how the Command Station subsequently executes a valid command, or how it talks to an accessory. In the case of the Nextion based Throttle controlling turnouts, there are two command types a DCC++ Command Station understands. These two are:- <a address subaddress state(0/1)> and <a linear_address state(0/1)>. The address component of the first option is an address value between 0 and 511, and a subaddress value between 0 and 3. this yields 2044 unique addresses. In the second form, linear_address is any value between 1 and 2040. It's important to note that there is no native support for an address:subaddress where the subaddress can be in the range 0-15. It is possible however to do a conversion within the Nextion Throttle code. The current Throttle uses the address:subaddress format (511:3), and I'd use the linear_address method for single "button" operations. I therefore think the best solution would be to provide a visual display of all three formats:- Linear, 511:3 and 127:15. It would be nice if updating any one of the formats would automatically reflect in the others... There is another more advanced method to control turnouts which was not used by the initial throttle designed by Dave Bodnar. That method revolves around turnouts being defined within the Command Station itself, a throttle then being able to request details of those turnouts, and then able to control them using an identifier ID given to them by the Command Station. This latter method is ideal when more than one throttle has access to the Command Station, and is the format I'd use if and when I do a re-work. End of further ramble. Just thought I'd let you know I haven't been sleeping Hope you have a Happy Christmas Norm
Hi Norm, and all others currently here: Merry Christmas and a good, fulfilling NewYear to you all! Norm, your explanation deserves a pinned memo: I never before saw such a fine, concise and clarifying explanation of decoder addressing. Thank you. Just one question: David B.'s Nextion design was originaly meant for wireless comm's (HC12), with the intention more than one could be sending commands to the base station. 1.when you use "command station", do you mean the actual command station ie handheld throttle, or the base station (which sends DCC information to tracks and or decoders)? 2. when Dave's Nextion throttle A sends a turnout command to "close" turnout X, and another Nextion throttle B after that sends the same command (or for that matter, a "open" command), what could be wrong with that? Meaning: what is the advantage of That method revolves around turnouts being defined within the Command Station itself, a throttle then being able to request details of those turnouts, and then able to control them using an identifier ID given to them by the Command Station. ?
Thanks for the kind words! I was actually only trying to clarify it for myself!!! Some answers: 1. Not quite. Command Station = Base Station in my speak. Handheld = Throttle 2. Nothing really I guess, except that if each throttle displays the Actual turnout position, as well as Speed and Function settings of any available loco, it adds an amazingly (warm) feeling of togetherness. But more seriously, knowing that the position you see on your Handheld Throttle has been set like that as a result of the Base Station actually sending the command to a turnout, and sending you a courtesy copy is where the value lies. I find this of the most value when there is a wireless link between the Throttle and the Base Station. How the Throttle code works (or should) is to first send the required command to the Base Station, and then only update the display after receiving the very same instruction in return. The update is of course sent to every active throttle. Kind of a "closed loop" acknowledgement system Meaning: The main advantage is that each Throttle does not need to retain any details of turnouts and locos at all. By simply "Connecting" to the Base Station, the current state and list of all configured turnouts is downloaded and ready to be displayed on the throttle. A varied number of pages of turnouts can even be dynamically created. How to implement this concept for single action buttons might require some head-scratching Hope that helps, Best Norm PS. I'm having a Great Christmas - I trust everyone out there is as well!!!
Hi Erik, just to whet your appetite, here is an Alpha version of the 2D Throttle which includes the beginnings of an additional button object. Note that I changed the Nextion to Arduino Baud rate down to 9600. The next steps are to add single pulse and toggle functions to the button (Toggle actually working, andto provide the Address:index option. I have some ideas in this area...
Hi Norm, you could also use the WiThrottle protocol, but in any case, we are adding to how bi-directional communication works with throttles, so if you haven't already, it would be really great for you to work with us on Discord if you can, or if not, I can try to ferry information back and forth. I assume you've seen the newer commands not only for linear accessory addressing, but also the much simpler Function button addressing.
Hi Fred, I certainly am happy to contribute where I can. The key words are "where I can".I have been trying to learn a bit of C, and C++ is very difficult for me. I had done quite a bit of work with @Atani who very patiently did most of the work... But it had given me ideas to ( attempt to) redo the Modified Dave Bodnar throttle, trying to incorporate what @Atani had shown me, and also to carry on from where we'd left off. I have recently joined Discord, so will no doubt show my aged face from time to time Norm
A lot of us have had the same idea. My favorite of all the throttles so far is a variation of the Bodnar Nextion throttle by the gentleman from Italy. They had the best graphics. There was another here where a guy built 3 throttles with a 3D printed case and used a snap-on drill battery for power which was interesting. He also improved the graphics, but he abandoned DCC to do something in MQTT and his own decoders. I like physical buttons so wanted a hybrid with buttons for at least a few functions like the horn.
I'll look into the "Italian" version. Ive kind of been out of circulation for the last year so have lost touch☺
Hi Fred, as you saw I have joined Discord and now wish to provide some feedback -and I can't for the life of me find my original "Ticket" and the subsequent replies. I'd like to thank the guys because the solution proposed works absolutely perfectly! I'd also like to point out one small typo in the config.h file:- the 3 "SERIALx COMMAND" lines should be "SERIALx COMMANDS" - easily spotted but did cause a little distraction Cheers Norm
Could you give me a link to the "gentleman from Italy's" work? I use 3.2" Nextion display on my handheld controls and they seem to be hard to get at the moment. Out of production? A bigger display wont fit without redesigning the whole thing (and it's more expensive), but a slightly smaller, 2.4", could maybe be a solution. Just change the lid, and with a smaller display there could be room for an extra button or two.
I'm not positive but this might be the link you are after.... https://www.scalatt.it/forum/viewtopic.php?f=117&t=15474 Sumner
I just had a quick look and it seems that "the italian gentleman" also use a 3.2" Nextion display. Hopefully it will come into production soon again.
Is ( THIS ) and ( THIS ) what you are looking for? I wonder if they are also out of stock since about every other place I looked was out of stock. I there any way a 3.5" might work. They seem to be available, Sumner
They seem to be out of stock in many places, but obviously not all. The manufacturer states "out of stock" and nothing moore. I'll have to check if 3.5" would fit, I think it's too big. It could maybe work for the italian guy.
I'll have a look at his HMI file if it's available... I had reworked most of the Dave's images to fit the 3.5in display. Norm
Hi Sumner, I had a look at the Version in the link above, and I have two comments 1. The guy (whom I had tried to contact a few years ago and had never responded) has certainly done an amazing job with the graphics and layout! At the time I had asked him to share his graphics so that we could improve the aesthetics of the modifications I had made and were widely published 2. I'm personally quite disappointed that he never contacted me, requested any collaboration, nor gave me any credit for the work I had done. He essentially plagiarized my work and took the credit. Specifically, the code is exactly what I had published at the time, with the exception of the "Version" number which is changed to "5.00". The Nextion HMI structure indeed uses the initial Dave Bodnar's Nextion work (which I had asked Dave permission to do, and gave him due credit), and then added the Turnout and Routes pages, graphics and supporting Nextion and Arduino code. Now that I've got that out of the way and set the record straight, I'm not prepared to take the issue any further. I think that the work he has done is magnificent, and I'd absolutely love to incorporate his graphics and revised layout in my current extensions I'm busy with. I'm going to contact him directly and request that we work together using his graphics, Dave's underlying code and sketch, as well as my extensions to proceed further. Al the best Norm
Just a note of caution: both on David Bodnar's Nextion throttle schematic as on the copied version of the italian's schematic pins 2 & 3 must be connected to the rotary decoder, and pins 4 & 5 must be connected to the Nextion. Not the other way round as in the schematic. The rotary encoder must be connected to the hardware interrupt pins (2 & 3).
I guess I'm confused by that. To me it looks like Dave's schematic is going to the correct pins on the Pro Mini according to the Arduino site... Why would the encoder go to the RX and Reset pins? As I said maybe I'm not understanding what your thoughts are. I haven't looked at the sketch but the Nextion is connected to Input/Output pins which seems logical. Sumner
No David Bodnar's schematic is wrong Sumner. Digital pins 2 and 3 (which are leg numbers 5 and 6 to confuse matters) are the hardware interrupt pins. Ie these pins must be connected to the encoder for the interrupts to work. In David's program the following lines appear in void setup() Code: .... (my dots) static int pinA = 2; // Our first hardware interrupt pin is digital pin 2 static int pinB = 3; // Our second hardware interrupt pin is digital pin 3 .... (my dots) attachInterrupt(0, PinA, RISING); //interrupt on PinA, rising edge signal & executing the "PinA" Interrupt Service Routine (below) attachInterrupt(1, PinB, RISING); // same for B .... (my dots) This is evident as pins 2 and 3 (which are DIO2 and DIO3, connected to Pro Mini 5th and 6th leg) are the pins where interrupts, coming from the rotary encoder must be detected. Hence: the two wires from the rotary encoder must be connected to DIO2 (pin or leg 5) and DIO3 (pin or leg 6) Look on your picture: where you marked in black, outside the board, 5 and 6 you can see on the board itself a corresponding 2 and 3, which are DIO2 and DIO3. Nextion needs to be connected to the pins designed for SoftwareSerial, which are DIO4 and DIO5, meaning legs 7 and 8. Code: .... (my dots) SoftwareSerial nextion(4, 5);// Nextion TX to pin 4 and RX to pin 5 of Arduino .... (my dots) I tested it as such and it works, and David's drawing is wrong at these instances. PS: I am sorry to reply only now, I happen to see just now that you had posted your reply (on Jan 6th). Rgds Erik
