RE: Home shop CIM (Java vs. C++)

Moses wrote:

>Have you written much cross-platform code in java other
>than UI? From what I've read, experienced and talked to
>other programmers this may not be easy. Java is not near
>as cross platform as is thought - especially when you
>get away from UI.

Yes. The way that I got interested in using Java for embedded control
was that back in 1998 I developed the control software for a 12 axis
stepper motor driven machine and it was written mostly in assembly
language. After finishing that machine I decided that I desperately
needed to move to a more abstract language/platform and after
researching this issue I decided that Java held the greatest future
potential.

Since that time I have developed all kinds of Java based applications
from GUI based client side stuff to database driven server side
applications. But my especial area of interest is Embedded Java and
the following are my favorite Emebdded Java platforms:

http://www.systronix.com/tinistik/

http://jstamp.systronix.com/

http://jstik.systronix.com/

http://muvium.com/

http://www.ibutton.com/TINI/index.html

And I hope to be playing with this one before too long:

http://timesys.com/


Back in 1998-2000 it might have been true that Java's cross platform
capabilities were not 'up to snuff' but huge improvements have been
made since then and I have found that the cross-platform issue has
become a non-problem.

The Tini and the TStik come with ethernet capabilities built in along
with 1 Meg+ of memory for less than $100. Amazing...



David said:

>Open source is good, but I would not even bother with
>wireless ethernet in an area where machine tools are running.

I agree that wireless would not be a good idea for in the shop but I
have found that it works very well in the house, office and yard so
that one can move around with a portable computer or PDA and still
have access to the CIM system.

>My thought is that the best way to go about this is to get
>some of the projects that are already mature such as EMC
>and the PLC project to consult on a common software
>interface. [snip]

I agree here too about leveraging existing open standards wherever it
makes sense.

>I don't buy it, Java is not the way you want to go here. First
>off none of the platforms you mentioned above have every been
>at the same level of implementation when it comes to Java. [...]

Actually, the Java releases for Windows and Linux are in lock step now
(http://java.sun.com/j2se/1.4.1/download.html)and the Mac Java
releases are following these increasingly closer.

>Second there really is not rational reason to support Windows
>with GPL'ed software when we have a GPL'ed operating system. [...]

Well, some people like Windows and some people like Linux, etc. so if
Java runs equally well on these operating systems why force people to
choose one OS over any other if one does not need to? I prefer Linux
myself because it is rock-solid, modifiable and the price is right but
that's just me.

>Third I truely believe that you would be much farther ahead
>to implement in C++.

Which Operating system, version of C++ and Library API should a person
pick? Should one pick Windows, VisualStudio and the Microsoft
Foundation classes (if this is a GUI app, Linux, gcc and Gnome or
something Mac OSX based? Beyond this, if I want my realtime control
software to run equally well and unmodified at the binary level on PCs
and embedded systems (which use numerous processor types), C++ has
proven that it is incapable of doing this.

My position is that C++ has been around since the mid 80's and if it
were feasible to build a CIM system like the one we are talking about
with C++ it would have happened already.

>Lets face it, Java is a system that binds you to certain
>programming concepts [...]

The Object Oriented programming concepts are what give Java and C++
their incredible power. Beyond this, Java is the only widely used
language that was specifically designed to work in a globally
networked environment which is exactly the type of foundation that a
CIM system needs to leverage.

>and performance pitfalls.

Ummm, what performance pitfalls?

These 100% native Java embedded systems absolutely scream:

http://jstamp.systronix.com/

http://jstik.systronix.com/


This processor is a very fast JVM which runs on PICs:

http://muvium.com/


And the new TimeSys realtime Java implementation is both screaming
fast and represents some of the most advanced realtime software
concepts int he world:

http://timesys.com/

How much more speed does one need?

>Often it is easier to implement a bit of electrical handshaking
>between machines as opposed to complicate I/O networking. This
>is especially the case if the machines have dramatically
>differrent controllers.

From my experience I have found that it is much easier to simply plug
a controller into an ethernet network (snap one end of an ethernet
wire into the controller and the other end into a network hub, done.)
and let the software worry about the messy details of integrating it.
Of course this only holds true if the software was designed from the
ground up to work in a networked environment. To date, Java is the
only widely available platform and language that meets this requirement.

>As manufacture have learned building blocks are nice but
>the infrastructure to tie them together is a killer.

From a topology perspective, what can be easier than snapping a
controller into a 100BaseT ethernet hub using RJ45 phone-like
connectors? As for the software part of the infrastructure, software
platforms and development environments that were capable of
successfully supporting a building-block paradigm were not available
then but now they are (just barely, but they are here). This is why I
think this is an excellent time to start look at the concept of home
shop CIM.

>I've never really believed that the issues restricting adoption
>have been the lack of commodity technologies for the controllers.

By commodity technologies, I was not just referring to controllers but
also to free databases, cheap high-speed networks like Ethernet,
software and platforms designed from the ground up to work with
networks, etc.

>The issue always seems to revolve around all the hard machinery
>required to implement the automation and the supporting software
>edevelopment. The cost of a lathe an its CNC controller is nothing
>comapred to trying to integrate it into a prodcution line.
>The software developement effort can not be underestimated,
>this is why I believe that attempting to enrole as much
>existing software as possible is a good idea.

After researching the CIM idea for awhile now I am starting to
gravitate to the opposite view on this. PlasmaCam's software
(www.plasmacam.com) seems to be a good example of this position in
that it is a CAD/CAM system that was built from the ground up to serve
a specialized purpose and it does not depend on any existing CAD or
CAM software. From what I can see this strategy is making money
'hand-over-fist' for PlasmaCAM and I think it is pointing the way to a
trend.

My goal is to help develop a lego-like CIM building block framework
which will allow people to 'snap together' CIM systems using
standardized hardware and software components to solve their
specialized needs.

Anyway, this has been a very interesting C++ vs. Java discussion,
David, and I am open to continuing it if you would like.


Ted