Thanks..., wiping a tear....
And give my greetings to "Steve Dockter".....


Or am I wrong?
Going to delete this post after your answer...

/Marc

You're right! We are friends and co-workers. He speaks highly of you and sends his best regards!

Yeah, yeah....

Can't delete my post after a re-post....
Greetings back to Steve.
And hopefully the forum will be back "as normal" ASAP....

Take care,

/Marc

Regarding custom object building, I have another question: How to create custom objects on an x86_64 development station and cross-compile for Raspberry PI? When building custom objects, programs are compiled per designer guidelines, as follows:

gcc -g -c $pwrp_inc/myclass.c -o $pwrp_obj/myclass.o -I$pwrp_inc -I$pwr_inc -DOS_LINUX=1 -DOS=linux -DHW_X86=1 -DHW=x86 -DOS_POSIX

Then, update classes in rootvolume, BUILD and simulate. Works great.

But, for a target raspberry node, it seems a custom object requires an ARM-Linux compile? If so, what are the correct gcc switch settings for Raspberry Debian ARM-Linux?

To clarify, I have been running Raspberry PI PLC and Operator nodes without issue until introducing custom objects. I am confused how standard objects can be easily cross-compiled, but custom objects require a two-step process? Does this mean I should "compile from source with new classes" to obtain all of the standard functionality (including off-line class help)? Or, can I stick with the end-user's Class Editor method to keep the officially released, production code pristine? Perhaps an alternative is to switch to an ARM_Linux Development machine to build custom objects for ARM_Linux nodes and simulation? A development station was loaded onto a Raspberry PI 2, but performance is very slow due to SD Card access times.

/Ron

Hi Ron,

No idea, have never tried it but you have already the possibility to cross compile on your platfom.
If you don't worry, in first case, about the optimalization flags (it's based on bcm2708/Rpi1 anyways) and replace gcc with arm-linux-gnueabihf-gcc, create the object file and distribute to the operator station running on the Rpi...
Give it a try.... I am curious what will happen.
Personally I always compile native.
Cross compiling is an optimalization jungle. Especially related to Raspbian releases, which are backwards compatible with all (older) Raspberry Pi's boards...

/Marc

Marc,

I was reviewing your website and found your O/S comparisons on Raspberry PI2.

"Arch Linux on the rpi2 is for me, personally, powerful enough to work with a Proview Development station. Especially the time for opening the project root volume comparing to Debian is mystical.

For the same project (runtime) Arch Linux eats around 2% of the CPU, comparing the Debian around 7%

Arch Linux needs 12 sec. to open the root volume against almost 2 minutes for Debian. This can be "suspicious" or amazing blazing fast."

Based on your review, I will load Arch Linux onto an RPI instead of Jessie Debian. With your reported improvement in performance, a development station on an RPI may not be so bad after all. Also, I am wondering if a USB hard drive on an RPI may improve performance as a development station?

Compiling from a development station to a targeted node of the same processor family does seem easier than dealing with the perils of cross-compiling. While the low cost of Raspberry is very attractive, an embedded x86_64 processor may be a better choice for commercial control applications.

/Ron