On 8/15/20 12:13 PM, John Dammeyer wrote:
The PC is complicated and people are obliged to use an OS they really have no
control over. (Unless they want to learn the complete Linux OS ins and outs).
Depending on your experience and education any electronic device can be
easy to understand to total magic. Linux is open source so one can argue
that the user has complete control over the OS. PC's do have some secret
firmware that the hardware vendors guard very closely, but in most
instances much of it can be turned off or ignored for use with real time
Linux. Any device that will be used as the GUI will be complicated. A
smartphone is far more complicated than a PC and runs software layers
that will be obfuscated for years beyond their use.
Where do we draw the line as to what is complicated or not complicated?
A microcontroller driving an LCD for the GUI is far less supported
(developer man years) than an x86 PC. If we replace the PC with a
microcontroller and LCD display how much more work will it be to have
all the open source GUI's that LCNC already has for me to freely
customize for any given application? Sounds like lots of loss for what gain?
CNC machines are not plug and play. A fully functional CNC machine is
not something that an untrained operator can just walk up to and start
making parts. How dumbed down are we targeting a new CNC controller?
Something for desktop CNC routers? Even 3D printers are not just press a
button and come back when it's done unless the print programs have
already been proven on that printer model.
The Orange Pi is generating steps� >400Khz and runs LCNC for cheap and
is not a PC.
Same issue. Still Linux and still a complex OS along with video cards+USB+hard
drive support that appear to screw up latency with parallel port outputs.
The Orange pi is an ARM Linux PC with an on chip microcontroller. The
microcontroller does the job of some Mesa card functions. Latency is not
a problem with the Orange pi.
I'm looking for pathology to support a theory for anti-x86 PC machine
control sentiment.
I don't think it's anti-PC as much as PC + external motion control card. Where
in the past with low end VGA cards one could get high speed low latency it's
now PCs w/o parallel ports and built in video that makes a PC a bit of a crap
shoot.
Onboard video hasn't been an issue with latency for the past 10 years or
so. I have been using AMD motherboards for the past 20 years without any
onboard video causing latency issues. I get $10 PCIe LPT cards for my
x86 PC's all the time that work well with software stepping and a $10
BOB. If it says WCH CH382L on the chip it usually works, even with EPP
and a Mesa card. EPP is only required for the LPT port to work with a
Mesa card. EPP is not required for software stepping to a BOB. This
driver was added to the kernel for Dev. ID 3050, Date: Sat, 26 May 2018,
Kernel 4.14
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/patch/drivers/parport/parport_serial.c?id=c9a104e23cb8ff37ddeb788f7d57b3b8d1a030ab
<https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/patch/drivers/parport/parport_serial.c?id=c9a104e23cb8ff37ddeb788f7d57b3b8d1a030ab>
Debian also back ported this to earlier kernels since it is working with
Kernel 4.9
What am I missing here? Is this anything more than PC bad and
micro-controller good?
Enter the 'micro-controller' which is much faster with more memory than many of
the PCs from 20 years ago and a simpler RTOS and it appears like the perfect
solution.
However, we're back into project definition and user interface issues at this
point.
The BeagleBone running MachineKit and its two additional PRUs already is an
inexpensive 32 bit solution. And it has video although rendered rather slowly.
But we're back into still running Linux under the covers and the video is the
limitation.
Yes the Orange pi is very similar to the BBB with its two PRU's. The
orange pi has one integrated microcontroller.
So I agree with Bari, before promoting the low level solution as this processor or that processor is great and now let's make a CNC system how about defining what exactly is wanted. Not just to get rid of the PC.
Perhaps the proponents of such a system might create a list starting with the
user interface which will include display and user input mechanism along with
I/O requirements. Specify that first.
Then start looking at what sort of open source hardware is out there that will
fit the specifications.
The other direction appears to be: "Wow! I really like the STM32 or OrangePi or
XXXX! I want to replace LinuxCNC with that because I know it can do 300kHz stepping and
it works on a 3D printer."
So what are the specifications of this 'replacement'?
Screen size and resolution and graphical abilities?
Networking capabilities including Ethernet _and_ Controller Area Network?
User interface including touchscreen, keyboard, keypad, mouse, trackball, MPG
(and how many)?
Closed Loop motor control or open loop motor control?
If closed loop is there an encoder from each motor in and PWM out?
Step/dir or Smart Serial?
How many axis?
Ancillary devices like Tool Changers? Pick and place for automatic placement
of raw stock and removal of finished stock for dark room operation?
I believe until a clear definition is posted of exactly what the hardware must
control, choosing a processor or processor module is pointless. And when I say
clear definition I mean a document that could be given to a developer in a
locked room; it has to be complete.
John Dammeyer
Even a block diagram of the systems architecture would be useful to
point out all the issues and potential risks and developer time required
to undertake such a project.
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
