Re: [CAD_CAM_EDM_DRO] USB and ncPOD system

John Stevenson wrote:

>>> IMO - The Ncpod has some limitations which should be made clear to any
>>> prospective users.
>>>
>>> Each port is only rated at 20mA.
>>>
>>> Only one axis can be jogged at a time (multiple axis moves are fine
>>> under code). In truth - this hasn't caused me any problem.
>> And with a windows keyboard you can only select one at time anyway ;)
>
> No. Hold down the up arrow and left arrow and Mach3 will move in two directions at the same time.
> It will move in all three if you include the page keys.

OK - the *USB* keypad does not allow that ;)
But the corner arrows do give diagonal moves - which I forgot.
Not sure what ncPod did with those and the module is not here to check :(

>>> PWM output is 75kHz, it's output voltage is only 3.5V and it will not
>>> work with much of the existing hardware out there without modification
>>> or additional hardware.
>>>
>>> Index pulse input doesn't work with Mach due to latency problems and is
>>> not supported currently. Whether it ever will be would be guessing.
>> Probably a separate discussion. Need code within the ncPod to handle this,
>> because windows is not a real time OS. The parallel port only manages it
>> because art has moved the essential code to the driver that sits in front of
>> windows? I seem to remember the same problem with latency affection other
>> modules as well.
>
> I thought this whole idea of going to seperate real time boards was to take away the fact the box doesn't need to be in real time.

The point I'm making here is that some functions can be controlled by the
computer, others need help outside the box. The USB port has different
characteristics to the parallel port so change the rules on what needs to be
ported to external hardware.

> The underlying problem is that the board is only supplied 5v and most spped controllers require 0 -10 volts, some VFD's are now on 0-15v.
> Perhaps the answer is a sererate supply from the speed control much like Arturo Duncans C11 / C11G boards ?

That is nothing to do with THIS discussion. Changing voltage levels and
supplying opto-isolation or level shifting for hardware that is not capable of
handling the current limitations of any of the output devices is a simple
problem to solve. It's the same for any computer parallel port.
ncPod drives all of my HARDWARE quite happily without any other hardware, and
all of the VFD's I've looked at allow you to select the range over which they
work. With an upper limit of 10V or 24V depending on the supplier.

Getting the lathe spindle synchronised with the other axis requires the
software to be able to work in real time and that is something that windows
does not like doing, so some piece of hardware is needed to do the job WELL.
The question is what does that hardware actually have to do.

Don't go off on one when I say this John ;) but a 75GBP linux board running
EMC2 is more than capable of sorting this out, and what is the difference
between using linux on the slave real time box as opposed to the proprietary
OS used in GRex or or ncPod or some other real time board. At least WE can
then play with the code while we are restricted to what we are supplied
otherwise :)

>>> It will ONLY work reliably with USB 2.0 ports - even having legacy USB
>>> support turned on in the PC bios will often cause "The pod has ceased to
>>> respond". This particular problem has caused more support queries than
>>> any other despite the information being posted numerous times.
>> Much the same sorts of niggles as the parallel port? Not really the hardware's
>> fault, but rather the crap underlying design of the platform and OS ;) What
>> are the limitations of a good USB2 port, and what do we need to get around them?
>>
>>> There are also still a few other issues with the Mach ncpod plugin, Art
>>> is aware of these and they will be fixed in due course.
>> Nice to see this summary, it would be nice to have a little more data on the
>> ncPod and perhaps it's own list rather than discussions around several. But
>> since there are several uses for it it comes under several umbrellas and this
>> group is not limited to a single product or area of computerised machining.
>
> It does have quite a dedicated list going for it on the Mach3 web forum and the yahoo group and has been worked on for a while.

But THAT is relating to using the module with Mach3 and any discussion of the
other software options will be killed there. The basic ncpod is a nice piece
of kit and is not reliant on Mach3. In fact some of the limitations to its
performance in Mach3 is DUE to Mach3. The ability to download gCode DIRECTLY
to ncPod and run it from there may well provide a solution to the lathe
problem since it would not require a return path to the host computer.

I have to admit to an ulterior motive in pushing this since the DRO350 box is
about to grow a major speed bump, and will have a powerful co-processor with
USB and/or ethernet link to the computer. Scott is going to make the code base
for the co-processor open source, and this will allow a number of expansions
based on a starting point of the actual position of the machine as read from
Chinese or Glass scales. So I'm building a portfolio of problems and solutions :)

--
Lester Caine - G8HFL
-----------------------------
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird Foundation Inc. - http://www.firebirdsql.org/index.php