Screen Editor Limitations in Guide conclusion

[Diego]

Hello, there is a previous post about some improvements to make more friendly the screen editor which I fully agree. The present is a conclusion that I've taken after programming for 3 years in Guide an now in other systems for Electronic Mobile Solutions. The Guide software is useful only for controllers, sensors and others except Display, because the resources destined to have better tools for design great images for end-users in displays are not in discussion in guide development workbench.
The final target of Danfoss is have a programming tool to make its hydraulics works (which make it perfect I have to say., Eg :Compliance blocks, import/export blocks, etc), but that only has to resolve some basics in graphical needs.
In my new designs I'm thinking to buy other customisable displays whose programming tools improved real graphical experience for programmers and end-users.
Summarizing: If you don't care graphical image capability in edition, keep GUIDE. If you do, better you buy other programming tool and other display mark (yes, is more expensive in the beginning but the reduced time dedicated and best final end-user's graphical solutions will equalize your pocket with the benefits of better displays' solutions).
Best regards. Diego.

[Marbek_Elektronik]

Do you speak about classic screen editor or vector screen editor ?

[Diego]

Hello. In both cases. Now I'm making some examples in other software tool for mobile electronics (P@rk3r) and I'm discovering real graphics tool for 7" displays! Danfoss is years behind to give to programmers such resources! Regards.

[Thomas]

Hello PLUS+1 FORUM community! 

Diego brings up some valid points about our screen editor.  Although we have made some incremental improvements in our screen editors, we know we have more room for improvement here. 
Our Displays and screen editing tools are currently a strong focus for Engineering organization and we intend to introduce new, industry-leading products and capabilities that will make the PLUS+1 development platform more powerful, easier, and faster.

Thank you all for providing feedback to us.

Thomas

[Diego]

Hello again, it is good to see that the words have made some echo effect. It will be interesting to know when these powerful, easier and faster improvements will be done and release to programmers. Regards. Diego.

[Thomas]

Hello Diego!

I cannot promise any time line when we will see it implemented. Some of these updates are rather fundamental and will take some time.
But I must underline that your feedback is very important and that we are trying to implement as much as possible as soon as possible.

Every second week we are evaluating new feature requests and ranking them to make sure we are going for the most powerful ones.

So look out for the next release, more goodies will come 

Thomas

[FluidPowerTom]

I suspect that it was my post that Diego was referencing.  We use PLUS+1 microcontrollers as our primary mobile controller offering, but for anything beyond a very, very basic display need I am using a different brand of display.  The nice thing about the GUIDE software being CAN protocol agnostic is that you can fairly easily interface with any CAN display.  I've done a couple of systems now wherein we used a PLUS+1 microcontroller and a non-Danfoss display. 

The only real challenge is that many displays don't allow CANfreestyle (just J1939 here in the US), so in GUIDE you must manually construct your CAN ID from all of the values that make up a 29-bit ID (if using J1939).  Once I got comfortable doing that it wasn't an issue.  It's a bummer that the PLUS+1 displays are the way they are, and the changes needed to even get them into the same ballpark as the other players are enormous.  The displays that I often spec into the systems that I program use CoDeSys v3.5, and out of all of the platforms I've used it is by far the best.

edit:  my suggestion to you guys at Danfoss is, at least for your displays, to offer concurrent support for the CoDeSys platform.  The amount of work that I imagine to be involved in bridging the unbelievably extreme gap between the GUIDE screen editor and what your competitors offer is such that I'd rather see movement towards what I know to be an excellent platform (CoDeSys).  Frankly, the displays that I prefer now have some nice features, but 95% of the reason that I use this other brand is because of the CoDeSys platform.

[enigmapaul]

FluidPowerTom -

Sorry if this is a naive question, but what is the CANFreestyle protocol?  I couldn't find any specifications on it on the web.

Thanks,

Paul

[Marbek_Elektronik]

If you want to send a message, you choose an ID and send e.g. 8 Data bytes, you want to send.
For example:
Id 0x400 for sending all inputs form MC050 to DP600, and some analog inputs:
data0-data4: digital inputs, data 5-data7: analog inputs or counters.
Id 0x401 for sending parameters to display.
Id 0x402 display sends outputs to MC050,
and so on.
You can build your own protocol!