New PanelDue 1.16beta1 firmware

dc42

I can't swap tools when my delta is homed, due to moving to a "purge zone" in the tfreeX.g file.

I usually move down 100mm, then swap. Doing that and going to tool 1 works fine. I don't rehome or anything, just swap to tool0 (for filament loading I do 1, then 0), perhaps that's my issue.

What I meant was that the tool change files are not run if the printer is flagged as "not homed" i.e. the printer doesn't know where the head is because you haven't homed it since you started it. So if you have previously homed the printer and not turned the motors off since then, it doesn't matter where the head is when you change tools.

DjDemonD

@kraegar:

@dc42:

@kraegar:

I haven't tried the new version yet, but had a question on the previous version. When I was testing my switching hotend, I noticed if tool 0 was active and I pressed the icon for tool 1, it immediately did the full filament swap (pre, free, post) to tool 1. However, if I hit tool 0 to change back it would only run pre/free. To load the filament it tool an extra press on the tool 0 icon.

In addition, is there a way on the paneldue to indicate which tool is active?

That sounds odd to me. When you select and/or deselect a tool, the tfree file for the previously selected tool (if any) is run, then the tpre and tpost files for the new tool are run. The exception is that if one or more axes is not homed, the file sare not run.

You can tell which heaters are active because the current temperature is shown with a red background. I am open to suggestions for how to show which tool is active, bearing in mind the limited space available.

I can't swap tools when my delta is homed, due to moving to a "purge zone" in the tfreeX.g file.

I usually move down 100mm, then swap. Doing that and going to tool 1 works fine. I don't rehome or anything, just swap to tool0 (for filament loading I do 1, then 0), perhaps that's my issue.

Why not move down 100mm at the end of your homedelta.g file?

This is probably the one thing I liked about marlin rc8 on a delta it automatically moves down to a carriage position which allows full effector movement after homing.

kraegar

I'll have to think about that. Not sure if I always want to move down or not.

iDevelo

Looks good!

DjDemonD

Excellent, great update, no issues.

DADIY

Hi David.

Are there any instructions for setting up eclipse to build this? I'm hoping its easier than setting up eclipse for building the Duet firmware as I never managed to get that to work.

dc42

@DADIY:

Hi David.

Are there any instructions for setting up eclipse to build this? I'm hoping its easier than setting up eclipse for building the Duet firmware as I never managed to get that to work.

How long ago did you try to set up Eclipse for building RRF? It used to be much more difficult than it is now because of the need to use the temperamental Arduino plugin.

I use the same configuration (including cross gcc compiler) to build PanelDue that I use to build RRF and associated projects, just a different workspace.

DADIY

Probably last November I last had a go. Never managed to get it compile anything though

schneik80

updated and no issues. very nice improvements.

Fickert

Quick question in regards to updating. I hit erase and reset while plugged into my pc with a usb cable that only provides power. Now I cannot install the same driver I used for the Duet. Am I missing something?

As well, I cannot figure out how to download the windows version of Bossa. My pc always prompts me with it cannot open the .gz file.

Regards,

Dustin

dc42

You can find the Windows version of bossac in the Tools folder of my github RepRapFirmware repository. I don't think you need a driver if you are running Windows 10.

Loffy770

I have upgraded and noticed that Paneldue does often stop to read the temp while the webinterface displays temp correctly..

celulari

Thanks for the update!!! It Is possible yo add an option to turn off the screen? It's so bright on the dark

Thanks!

Doc_Pengu

Hello David,

Sorry if this is on wrong place. I have tried to search on forum, but not come across this problem.

I have little problem with my 7 inch screen and PanelDue.
Touch screen seems to be thinking thats it on portrait mode,
so….

When 1st cal point comes to screen to press, i need to press point where 2nd one comes (does not care if i try press in right point over the black spot) and when 2nd cal point comes, i need to press where 3rd point comes....
Touch screen is rotated 90 degrees. End of this calibration process i get all coordinates wrong

I seems to be thinking that in original touch screen code to Arduino, there in some sort on way to turn this right ?
What needs to be done to your code to correct touch screen rotation ?

Is it possible to get BIN file with this already corrected ?

I have tried to get my Eclipse installation working, i get ELF file end of compiling. BIN file goes 'missing', even it's on Post-build steps settings.

Thanks
Mark

dc42

Where do you get your 7" TFT panel from? Are you definitely using the code for the 7" panel?

The Eclipse project has a post-build step configured to convert the .elf file into a .bin file.

DADIY

I managed to get the PanelDue firmware to build but there were a couple of extra steps required that were not in the instructions that I found I needed to do.

For Eclipse I had to install the following extras under Help - Install New Software -
Arduino C++ Tools - org.eclipse.cdt.arduino.feature.group
C/C++ Development Tools - org.eclipse.cdt.feature.group
C/C++ GCC Cross Compiler Support - org.eclipse.cdt.build.crossgcc.feature.group

To get the elf file to convert to the bin file, the Post Build Steps under Project Properties -> C/C++ Build -> Settings Post Build Steps was updated to

arm-none-eabi-objcopy -O binary ${workspace_loc:/${ProjName}/${ConfigName}}/PanelDue-7.0.elf ${workspace_loc:/${ProjName}/${ConfigName}}/PanelDue-7.0.bin

The original used ${ProjName}-7.0.elf for the filename which was evaluating to PanelDueFirmware-7.0.elf but the output from the compile generated PanelDue-7.0.elf

Also the Arduino 1.5.8 from arduindo.cc didn't include the tools but I already had these installed elsewhere.

DADIY

Check your makefile , at the end there is the command that converts the .elf to the bin, you may find that if you run this manually that your path in the command is slightly wrong.

@Doc_Pengu:

Hello David,

Sorry if this is on wrong place. I have tried to search on forum, but not come across this problem.

I have little problem with my 7 inch screen and PanelDue.
Touch screen seems to be thinking thats it on portrait mode,
so….

When 1st cal point comes to screen to press, i need to press point where 2nd one comes (does not care if i try press in right point over the black spot) and when 2nd cal point comes, i need to press where 3rd point comes....
Touch screen is rotated 90 degrees. End of this calibration process i get all coordinates wrong

I seems to be thinking that in original touch screen code to Arduino, there in some sort on way to turn this right ?
What needs to be done to your code to correct touch screen rotation ?

Is it possible to get BIN file with this already corrected ?

I have tried to get my Eclipse installation working, i get ELF file end of compiling. BIN file goes 'missing', even it's on Post-build steps settings.

Thanks
Mark

Doc_Pengu

@dc42:

Where do you get your 7" TFT panel from? Are you definitely using the code for the 7" panel?

The Eclipse project has a post-build step configured to convert the .elf file into a .bin file.

Panel I'm using is from Aliexpress, friend of my bought it while back for some Arduino project, but it was never used.
So I ended to have it.

I have tried all BIN files from github repo for 7 inch panel and all of the seems to have same 'problem' with touchscreen rotation.
Need to look my Eclipse settings and get BIN file conversion working.

Any tips what part of PanelDue code could rotate touchscreen coordinations ?

Mark

Doc_Pengu

@DADIY:

To get the elf file to convert to the bin file, the Post Build Steps under Project Properties -> C/C++ Build -> Settings Post Build Steps was updated to

arm-none-eabi-objcopy -O binary ${workspace_loc:/${ProjName}/${ConfigName}}/PanelDue-7.0.elf ${workspace_loc:/${ProjName}/${ConfigName}}/PanelDue-7.0.bin

The original used ${ProjName}-7.0.elf for the filename which was evaluating to PanelDueFirmware-7.0.elf but the output from the compile generated PanelDue-7.0.elf

Thank you for the tip, that did do the job.

Mark

Doc_Pengu

All sorted now, got the touchscreen working correctly.
All I did is swapped order witch X and Y coordinates from touchscreen is read in UTouch.cpp

[[language]]
// If the panel is touched, return the coordinates in x and y and return true; else return false
bool UTouch::read(uint16_t &px, uint16_t &py, uint16_t * null rawX, uint16_t * null rawY)
{
	bool ret = false;
	if (!portIRQ.read())			// if screen is touched
	{
		portCS.setLow();
		delay_us(100);				// allow the screen to settle
		uint16_t ty;				// <- was tx
		if (getTouchData(false, ty))	        // <- was tx
		{
			uint16_t tx;			// <- was ty
			if (getTouchData(true, tx))	// <- was ty

Thank you David for nice add on to DuetWifi

Mark