Serial Touch screen support : advices needed

[Luc]

Hello ,

I am new on Smoothieware, so sorry in advance if my questions look weird.

I am looking for advice about adding the support for a serial touch lcd of this brand : http://nextion.itead.cc ( I am not related to this company) as I did not see anyone doing it.

This panel communicate by serial according these rules:

1. The instruction is end with three bytes "0xff 0xff 0xff"

2. All the instructions and parameters are in ASCII

3. All the instructions are in lowercase letters

After reading the Smoothieware documentation and sources and doing some tests I figure out that I should do the following:

1 - Add a new panel module in "src\modules\utils\panel\panels" for nextion panel, I see several samples of panels so looks possible.

2 - Disable gcode/command analysis for the Serial used by screen to avoid the "unknown command" error, done only if the nextion panel is set in config, may be by adding a flag in SerialConsole to filter serial vs USB? 

3 - Add some flags in config for the panel behavior:

    a - act as text lcd with +/- buttons (like encoder)  and Ok button

    b - act as graphical lcd with +/- buttons (like encoder)  and Ok button

    c - act as host with some custom commands to have full customized UI

    

Do you think is the right approach ? or is there another way ?

Thanks in advance for any advice / feedback

Also if I am in wrong place to ask these questions, let me know 

Luc

[Arthur Wolf]

Hello.

So, I think there are two possible ways to implement a panel like this :

1. The Smoothieboard controls the panel. A module in smoothieboard decides what is displayed on the panel, and sends instructions over serial to the panel.

This is for example how the reprapdiscount GLCD works.

2. The panel controls the Smoothieboard. The panel sends Gcode to the smoothieboard to tell it to move, or to get information like current position or temperature. This is what the paneldue does.

I really think in the case of an IMU like the nextion, doing 1 makes no sense, and would result in insanely ugly code. It'd never get merged into smoothieboard too.

However, with a nextion, 2 would be the right way to do things. It's exactly how the nextion was designed to work.

This means you don't want to create a new panel module, you just want to teach the nextion ot talk to the Smoothieboard, like if the nextion was a computer running pronterface.

Does that make sense ?

Tell me what you think.

Cheers.

--
You received this message because you are subscribed to the Google Groups "Smoothie-Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothie-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

[Luc]

Merci, Thanks for your answer,

Yes having the Nextion working as host is definitely the way to go I fully agree ( it is the point c of proposed behavior, points a and b are more for proof of concept and not essential) , that also how it is implemented in marlinkalimbra (https://www.youtube.com/user/MagoKimbra/videos  https://github.com/MagoKimbra/MarlinKimbra)

But unlike paneldue, because of communication protocol of nextion, no "\n" but "0xff 0xff 0xff" and  specific format for string, that may bring pollution on the event ON_CONSOLE_LINE_RECEIVED, and also need formatting for sending information back on Nextion, so my understanding it is necessary to add a filter/bridge, that would be the panel module role actually, as I need to teach smoothie to talk to nextion and not being disturbed by it. unlike the duepanel that can use raw commands like any host.

I already coded a filter based on parameter in config file, selecting which serial is the connection to nextion,

in kernel.cpp

switch( __mriPlatform_CommUartIndex() ) {

        case 0:

            this->serial = new(AHB0) SerialConsole(USBTX, USBRX, this->config->value(uart0_checksum,baud_rate_setting_checksum)->by_default(DEFAULT_SERIAL_BAUD_RATE)->as_number(), THEKERNEL->config->value( serial_checksum, filter_usb_checksum )->by_default("false")->as_bool());

            break;

        case 1:

            this->serial = new(AHB0) SerialConsole(  p13,   p14, this->config->value(uart0_checksum,baud_rate_setting_checksum)->by_default(DEFAULT_SERIAL_BAUD_RATE)->as_number(), THEKERNEL->config->value( serial_checksum, filter_serial1_checksum )->by_default("false")->as_bool());

            break;

        case 2:

            this->serial = new(AHB0) SerialConsole(  p28,   p27, this->config->value(uart0_checksum,baud_rate_setting_checksum)->by_default(DEFAULT_SERIAL_BAUD_RATE)->as_number(), THEKERNEL->config->value( serial_checksum, filter_serial2_checksum )->by_default("false")->as_bool());

            break;

        case 3:

            this->serial = new(AHB0) SerialConsole(   p9,   p10, this->config->value(uart0_checksum,baud_rate_setting_checksum)->by_default(DEFAULT_SERIAL_BAUD_RATE)->as_number(), THEKERNEL->config->value( serial_checksum, filter_serial3_checksum )->by_default("false")->as_bool());

            break;

    }

I have added a message type parameter with default value :

typedef enum  {STANDARD_MSG = 0, NEXTION_MSG =  1} SERIALMESSAGE_TYPE;

struct SerialMessage {

        StreamOutput* stream;

        std::string message;

        SERIALMESSAGE_TYPE type;

};

const SerialMessage DEFAULT_SERIALMESSAGE = { NULL, "", STANDARD_MSG};

and so in SerialConsole::on_main_loop
depending if it is a nextion connected based on flag set
check  '0xff 0xff 0xff' instead of '\n' as no '\n'
and add type nextion to message before sending to event

 if (has_serial_filter) message.type = NEXTION_MSG;

THEKERNEL->call_event(ON_CONSOLE_LINE_RECEIVED, &message );

So in GCode module reject these msg

void GcodeDispatch::on_console_line_received(void *line)

{

    SerialMessage new_message = *static_cast<SerialMessage *>(line);

    if (new_message.type != STANDARD_MSG) return

but in nextion module only read the message for nextion because message.type == NEXTION_MSG;

I can be wrong as I am discovering smoothy code but was looking the simplest way to do it.

I am just starting so only filtering is implemented currently.

Do you think I am going in wrong direction ?

Thanks for reading and really appreciate your feedback

Luc

[Arthur Wolf]

Hey.

I really really think the only correct way to do this is to teach nextion to be better at serial coms. This is very trivial stuff. I know of nothing that uses 3x 0xff as end of line, and know of thousands of things that use \n, so this should be considered a bug, and you should ask them to fix it ... It's very easy to fix : they should just let you choose whatever you want to send.

If they won't fix it ( which wouldn't surprise me ), then yes you need a module in smoothie to do this, but that will never get merged into main smoothie, it'll need to stay in it's own fork.

I think you shouldn't be interfering with serialconsole, but instead create a new module, that has it's own Serial object, that talks to the nextion. It needs to be all self-contained into it's own module, and not interfere with the rest of smoothie ( appart from disabling the "normal" Serial object if it interferes ).

BTW, I have 5 nextion boards laying around here, if anybody wants to help you with this, I can send them a nextion for free.

Cheers.

[Luc]

OK I think you answered to all my questions :  no change in smoothy will be possible to use nextion protocole - no problem 

I agree with you for the "easy to fix" but I won't spend time on it as I guess answer will be same as yours =  do you you own fork.  ^_^

Thank you for reading and commenting.

Have a nice week end. 

Luc

[Arthur Wolf]

I'm curious if you made any progress on this.

Cheers.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothie-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Luc]

Well I just coded the entry point based on your advice -
created a class SerialNextion derived from SerialConsole

Hook this class in kernel according the config.txt

serial.filterUSB       false

serial.filterSerial1       true

I am late on this project due to others activities, but will be on it soon, anyway now the hooking part is clear, the other parts are peace of cake 

[Michael Meyers]

I have a bunch of nextion displays, but i havent learned to program them yet. keep me posted

[Patryk Bonzanini]

it will be really great to have something better than old looking lcd with smoothieboard. in the meantime marlin usres got this:https://www.youtube.com/watch?v=0U2IhC5hKvs&feature=youtu.be

[Arthur Wolf]

Well if this works with Marlin, it will probably work with Smoothie too, they use nearly the same protocol. I have a bunch of nextion in a box if somebody wants to try.

--

You received this message because you are subscribed to the Google Groups "Smoothie-Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothie-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[patryk Gmail]

I can contribute financially to develop this, maybe someone else can also help.
If this is possible contact me

[Luc]

I have been busy with others projects and building my house so I got hard time to be in front of computer ^_^
I have put this on hold, but I will create a repo on my github (https://github.com/luc-github) and continue this porting soon if anyone is interrested 

[Supersaetto12]

Hi! Any news about nextion interface in Smoothie???

ManyThanks!