Running FW: 2.0(RTOS)RC5 (2018-05-22b1), DWC: 1.21.1
Tested on small print and no issue occured.
Just one glitch on first print (macro with delta calibration, heat and cooldown) when reloading DWC in browser caused "Emergency STOP". But can't reproduce.
Hi,
how the communication between electronics and PanelDue works?
I know, that it's serial communication, but is it only gcode messages, or some custom format?
Is there any documentation?
How hard would it be to add gcode command to scan available local wifi networks?
It would be great in connection with PanelDue and setting network, when steps are:
Scan local wifi networks
Pick network to connect
(Set network password)
The problem with that approach is that you can either mount the SD card as a removable drive, or the electronics can access files on it; but not both at the same time. Smoothieboard users sometimes get into a mess because they forget which mode it is in.
Ah, I didn't noticed. It seams that I'm one of those users 
I have never used USB thumb drives to transfer files to a paper printer, and I can't think of any reason why I might want I do so. My paper and 3D printers are on the network so that I don't need to do that. Perhaps you have come from the older generation of 3D printers where transferring the files physically on an SD card was the most practical way to get them to the printer, and you haven't got used to using the web interface yet?
"older generation of 3D printers"β¦ that's a fancy name. Maybe I'll start to using that. 
And yes, you are right. In fact I'm still used to using printer directly connected to computer. Even SD card is in my eyes cool think for printing gcode files.
I guess if you take your printer to a different location where you are unable to connect to a network, then you might want to transfer files to it via removable media.
That's one of the reasons, yes. Or some place, where is network unusable, like conference or expo, where wifi is so jammed, like there is no network at all.
But yeah, in these cases is SD card good option.
I've noticed, that when smoothieware is connected to the computer, sd card is mounted as removable drive. For uploading file is it slow, but it's great for configuration purpose. Any plans with that?
Maybe it's oldschool too
Neither the Duet be the PanelDue has USB host capability in the microcontroller, which would be needed to support USB storage.
What a pity. Ok, never mind
The standard way to manage files on the Duet is via the web interface. If you want to back up gcode files to a USB drive, why not do it on the PC?
The reason wasn't to backup files, but to transfer them to Duet some other way than SD card or Web interface.
It's like when you have your files to print with desktop "paper" printer on USB thumb. There is also ability to print them over network and from removable device on printer itself.
But never mind. When microcontroller can't do that, then I have to deal with it
As main electronics is usually somewhere inside printer and not exposed to user, PanelDue with LCD is something to interact with.
It would be nice to have option to load gcode file from USB thumb (save it to internal SD card if needed, mostly for cache purpose).
I know, that there is SD card slot, but SD card is fragile, small and USB drive is something more common. Not every computer have SD card reader, but almost every computer have USB port.
Ok, now it's working. I've created pull request on github repo. Characters are generated and tested.
Interesting issue was, that GLCD Font Creator can't create characters after 0xFF. So I had to setup lcd-image-converter with some postprocessing scripts to get it done. But now it's perfect
Testing screen:
I have made those changes, tested them, and committed them to github. I will make further unrelated changes before I do a release.
Great. I've now tested build and getting ready generated font characters (GLCD Font Creator not cooperating as I expected, needs a little bit tuning) and translations. I'll hopefully finish it soon.
I haven't noticed changing brightness makes it different. It's still the same buzzing no matter what level of brightness is set. It seams that it makes this sound when LCD shows dark pixels (most covers backlight). So most noticable it will be, when showing all black screen.
Hi guys,
I have PanelDue v3.0 with 5" LCD and I noticed little buzzing in buzzer (or somewhere near to it) on board when powered up. Sound is not much noticeable, but it is there. It gets much stronger when I switch to dark theme on LCD. It sounds similar like when motors is blocked.
It looks to me that the following changes are needed:
- members firstChar and lastChar of struct FontDescriptor need to be changed from uint8_t to uint16_t
- parameter to writeNative needs to be changed to uint16_t
- in UTFT::writeNative, translation should only be attempted if the character is <= 0xFF (but I don't think the translation mechanism is needed any more)
- a few changes are also needed to UTFT::write.
I will make these changes in the next beta of PanelDueFirmware.
Looking forward to that
The fonts used in PanelDue currently have Unicode code points 0x00 to 0xFF. Some of the characters you want are a little higher than that. So the first thing you need to do is extend the font range to include the extra characters. It looks to me that you need to go up to 0x17F.
After that, it should just be a case of ensuring that all the text strings are encoded in UTF8 format. If you are getting rectangles everywhere then I suspect the editor you are using isn't saving the file in UTF8 format.
HTH David
Thanks.
For starters I checked files for encoding, fixed that and reflash. Some characters worked. Nice
Second I tried to expand font array, but it is limited by uint8_t which has max value 255. Now I have to dig a litle deeper and use uint16_t.
Hi,
I have now PanelDue v3 with 5" LCD. But, that is just for information what testing device I have.
What I have tried to do is adding my (Czech) language to PanelDueFirmware. Cloning and compiling firmware was without problem. Adding language was pretty easy at first sight. But when I uploaded firmware to device, there was only rectangles instead of special characters (in Czech language it is Δ,Ε‘,Δ,Ε,ΕΎ,Γ½,Γ‘,Γ,Γ©,ΓΊ,Ε―).
I have looked on used fonts and discovered that Liberation Sans (even generated character map) contains some of those characters. But none of those special characters is displayed correctly on device. There are rectangles everywhere
So, my question is: What should I do to fix it?
Or, can you "point direction" where might be problem?
I think I can fix it by myself and then post pull request on github with Czech language, if you want.
