On 20/07/17 06:07, Johannes Fassotte wrote:
Forgot to add: the computer is running 64bit.

On Wed, Jul 19, 2017 at 9:05 PM, Johannes Fassotte <[email protected]> wrote:
Thank you for your input.

After reading your message I think it would not be beneficial to change my configuration of my milling machine. It presently uses a 7I80HD Mesa board for all its control needs which connects by a LAN connection to a desktop computer with a 3.3Ghz Intel I7 processor. Thus processing power is not an issue.

So I move on to the below not related to my original post on this thread.

I gripe all the time about the continued need to use of depreciated dependencies on newly rip build systems that are not to far behind the latest versions of Linux. Thousands of man hours by users have likely been needlessly expended trying to find these illusive and at times confusing items. A recent issue I ran into was working on running machinekit on Mint 18.1.  linuxcnc works fine on Mint 18.1 but Machine kit requires some run time dependencies that are not able to be installed since they can either not be found or are older versions of already installed items. It would be nice to have an override for such problems that would allow attempting to use the installed version for testing and development purposes.

Linuxcnc starts, runs and finishes in a strictly linear fashion.  Once started, its configuration cannot be added to or altered without stopping it.
It does not allow remote components, instantiated components, multiple remote actors all controlling it, does not have atomic functions, a messaging format that
passes data to and from remote actors and could one day replace NML etc............

If Linuxcnc fills your needs, use it.

The OS's that are supported are currently Wheezy and Jessie, we are looking at Stretch.
The reason Debian is used, is because it is stable and conservative. 
The likes of Ubuntu are forever chasing version numbers, bringing in backwardly incompatible new versions of 3rd party libraries etc.
That is without even going into their 'ubuntuising' of everything, then claiming copyright, which has caused Linuxcnc huge problems with what they can do with Ubuntu distros.

If you want to run Machinekit on another unsupported OS, you have to sort out the problems.
There is no need to use any other distro to run a machine, the problem occurs because people try to do everything on one computer, rather than have machine controllers
and a desktop in the house to do all the fancy stuff on.

The main problem currently is that the zeromq project decided to change its API to make it backwardly incompatible.

If we changed the code to match, all existing Wheezy and Jessie installations would stop working, unless we could backport the new libraries,
which then gives us a maintenance chore for ever and a day, instead of using off the shelf 3rd party libraries.

In regards to the my machinekit installation tesing on Mint 18.1. I tried to generate a pin.txt file on Mint 18.1 to make some .ini and .hal file changes easier for machinekit required changes for my milling machine but HAL could not be found with "halcmd show pin > pins.txt" and machinekit running and connected to my milling machine. Perhaps a ownership or linking issue. Running the command line with sudo does not fix this. Gmoccapy halshow works fine with this setup but other errors indicate missing runtime handlers for buttons or button events.

To do terminal commands AND have Machinekit running, you need to be on the same session.

Start with machinekit & from a terminal, then return to the terminal and run halcmd show pin
and you will see all the pins of components from the running session.


On Tue, Jul 18, 2017 at 1:11 AM, [email protected] <[email protected]> wrote:
The main features in multicore are only of real use if you are going to be using multiple threads / multiple cores for several processes all accessing the same data.

Even then the benefits on a 32bit  architecture processor can be limited.
A 32 bit MOV command for instance, is only guaranteed to be atomic, if the memory is naturally aligned on a boundary which is a multiple of 4.
Some ARM instructions are also handled differently and some instructions that would be atomic on x86, might not be on ARM.
Any instruction to move a 64 bit value on a 32 bit system, is going to involve moving it in 2 sections to two 32 bit registers,
which can never be an indivisible atomic operation.
All the ARM boards currently in use with Machinekit are 32 bit.

Add to this that you need > gcc 4.9 to get near the full C++11 atomic operations standard.
Wheezy, backported to 4.7 just scrapes through, but you need a minimum of Jessie and 4.9.2 to use C++11 properly.
It is proving a challenge to get BBB users to move off Wheezy despite the fact it is out of all support from Debian in May next year.
The fact that the images with 4.x.x kernels do not work because they use xenomai3, does not help.

The DE0-NANO is currently approaching end-of-life (in production terms) and I don't know if the FPGA programming works 'as is' with its replacement, or will require changes.
They are however still available and have the advantage of being multi-core, of sufficient power and memory (just) to compile their own libraries and Machinekit itself and self-contained.

The other option which appears completely overlooked most of the time, is use a proper 64bit computer with a FPGA card.
Extremely powerful, fast and flexible.
There are quite small form factor PCs around.

The alleged 'space saving' often quoted as a reason for SoC boards, is most usually negated
by wiring emanating from them that resembles explosions at a spaghetti factory :-)

Machinekit is nothing to do with BBB or any other ARM SoC board. 

If you have some application that requires to run it to its full potential, with fully atomic operations where possible, that is the answer.

regards


On 18/07/17 05:48, fairbanks-john wrote:
I was going to order a BeagleBone Black (BBB) computer board today but read about MutliKore and put the BeagleBone Black order on hold since I would really like a board that has multiple CPU cores to be able to implement MultiKore features in machinekit. I read that the DE0-NANO-SoC board was being used during testing by at least one tester but would like to know if that is the recommended SBC board or if the development work that has been completed recommends another board to insure compatibility with machinekit.
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.



--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Reply via email to