Custom software for RV1S/RV4S

Started by arvydas, August 20, 2015, 12:33:35 PM

Previous topic - Next topic

Jason

Quote from: Mike on August 20, 2015, 11:55:05 PM
Quote from: Jason on August 20, 2015, 08:29:39 PM
so I can wire the FT2232H mini module up to the RV ISA card via some appropriate
glue logic
Maybe an FT4232H so you can also do the COM ports via USB with the same chip? Not looked at the FTDI data to see if you can do 2 com + bus emulation but it would be a very neat solution.

I ended up using FT2232D because it is 5v.
The ISA card in the USB adapter is totally USB Bus-powered, no extra PSU required.

trev

This is very clever stuff, well done.

Trev

Jason

Last night I got a composite video to USB capture device hooked in via the replacement
PXC2_95 and Frame_95 DLLs and the picture comes up in the calibration screen within
RVplace. ;D The code is really hacked together with quite a few hard-coded "assumptions"
which make it a fragile but it works and proves the concept.
I moved the USBtoISA code across into Frame_95 (even though it doesn't really belong
there) so the application automatically loads it eliminating the need for a separate .exe
to inject it into RVplace.

The quality of the captured composite is shockingly poor. I'm busy today but this
evening I will try hooking the camera into the Y input of the S-video of the capture
card as they often have better bandwidth.
An alternative solution may be to use a USB C-mount camera. However, they are too
bulky for the fid or flying cams an RV4 (mine is an RV1s and I never really use the fid
cam).

I'll post a video of it all tonight.


Jason

So here is it working, latest build of Windows 10 x64.
https://flynn.uk.net/Win10rv-1.m4v

Using a Startech USB capture device (Empia em28xx) rewired internally for the composite to enter the IC on the Y input of the Y/C in a vague attempt to improve bandwidth.
The DSP board and USBISA adapter is completely USB bus powered.

I'm having problems with the reliability of the em28xx capture which doesn't seem to work through every USB port or hub so I'm looking for an alternative.

You'll notice homing is slower than usual. This is due to the fact the homing procedure moves the arm one step at a time so is extremely IO intensive.
Once placing, most movements are large and the IO rate drops massively so the latency through the USB is not noticable and speed seems normal.


trev

Well done, this is impressive.

Trev

basemetal

I have just found an installer soft for something called "Genesis". It was on some stuff I got from dc a long time ago. It appears to be the next version of the RV software by a company called Versatek, however it seems to be for a different machine - not the RV, but using the same feeders.

It installs on my win10 64bit machine. Not sure where to post it because its an exe file.



trev

I have heard it's for the Q Placer. No good for RV1s or RV4S but it did use the same feeders.

alanambrose

I must have missed a few ( years :) ) messages on this thread.

Jason - very impressive work.

>>> via my USB to ISA adapter.

Something you made? There's no sound on the video?

Let me catch-up :)

So to summarise, you're running the stock RVS software, but with your own hook dlls, allowing you to squirt the stepper move commands down to your USB adapter and the old stock ISA board. And you've hooked the video capture commands in the RVS software in order to capture video using a modern camera over USB. You've rigged up a mount for that in place of the stock one? What does that look like and does it use the existing lens? You made your hook dlls in Borland C++?

The result being that...it effectively decouples us from relying on Win95 and old ISA motherboard machines? Are you still using COM ports on your PC to drive the feeders etc or do you have one of the set-ups where the COM ports are on the ISA card?

Alan

Mike

Quote from: alanambrose on May 13, 2021, 05:12:03 PM
And you've hooked the video capture commands in the RVS software in order to capture video using a modern camera over USB. You've rigged up a mount for that in place of the stock one?
No - using a composite video to USB capture device with the original cameras.
Quote
Are you still using COM ports on your PC to drive the feeders etc or do you have one of the set-ups where the COM ports are on the ISA card?
I'd be surprised if the COM ports didn't work via standard USB-serial converters, the only issue I can see is you may need to be able to force them to be low COM port numbers - this is usually just a case of fiddling with driver configuration.

alanambrose

>>> No - using a composite video to USB capture device with the original cameras.

Ah, and a custom replacement for the Imagenation dlls.

>>> I'd be surprised if the COM ports didn't work

Win10 and Win98 are still sufficiently compatible that old com code still works?

Well Jason's work moves us quite some distance along. An optional next step would be to replace the DSP card with a home brew with the same hardware and software interface. I don't think it's doing much (well in 2021, maybe quite a bit in 1995) except playing out the move commands on 4 channels in parallel (often not in parallel) using the acceleration profiles in ramp.sys:

http://www.anagram.net/nuts/Versatronics/Contents%20of%20ramp%20dot%20sys.png

Without getting ahead of ourselves, we can probably eventually do a better job of the dsp board by taking care of the snap, crackle and pop derivatives - the machine movements are rather jerky after all. It would be easy enough to reverse engineer the dsp function with Jason's adapter and a real DSP board by plugging in known move commands and observing the timing of the step output with a logic analyser. I've written the kind of code that does the acceleration profiles before, it's not super-complicated, say <100 lines of C.

Alan

alanambrose

Maybe (as people have suggested) even using an off-the-shelf 4-axis controller as there's precious little trajectory planning there, because (unlike a laser cutter, for instance) it doesn't matter much how the arm gets from one position to another, just that it does. I wonder, do we know whether there's comms back from the DSP board indicating 'done, end of movement' or does the calling software just wait for bit and assume?

Alan

Jason

>> via my USB to ISA adapter.
>Something you made? There's no sound on the video?

Yes, my own board based loosely on the FTDI app-note. It uses the slightly older FT2232*D* which is 5v.

> So to summarise, you're running the stock RVS software, but with your own hook dlls,
> allowing you to squirt the stepper move commands down to your USB adapter and the
> old stock ISA board.

Yes, stock RV software. When it tries to access the DSPs or UARTs on the ISA card, I trap
the priviliged instruction exception, analyse the offending instruction (is it an x86 IN or OUT
instruction, is it 8 or 16bit) and perfrom the IO operation using the FTDI MPSSE. (See
FTDI app note AN108 )
I then stuff the results from the USB transaction into the x86 registers, increment the
program counter over the "bad" instruction and resume.


> And you've hooked the video capture commands in the RVS software in order to
> capture video using a modern camera over USB.
<snip>
> You made your hook dlls in Borland C++?

Nope, I've written substitutes for the Imagenation .DLLs. The Borlands compiled
DLLs in the RV software call a relatively small subset of the Imagenation API and
it wasn't difficult.
Within my new DLLs I call the standard Windows "webcam" API. I have tried this
with a Composite to USB converter (commonly called and EasyCap) and also a
C-mount camera with native USB. The latter is far superior (not least because
the EasyCap drivers are pants and the C-mount camera is "driverless" i.e. uses
a Microsoft built-in driver: UVC )

> The result being that...it effectively decouples us from relying on Win95 and
> old ISA motherboard machines?

Yes, totally.

> Are you still using COM ports on your PC to drive the feeders etc or do you
> have one of the set-ups where the COM ports are on the ISA card?

My RV1S has UARTS on the ISA card. The main RVplace application, as far as
I know, will only talk to these (does anyone else have different?)
I vaguely remember one of the  command-line test utils using a regular
PC COM port at 0x3f8 or 0x2f8.

Jason

Quote from: alanambrose on May 14, 2021, 11:14:40 AM
Maybe (as people have suggested) even using an off-the-shelf 4-axis controller as there's precious little trajectory planning there, because (unlike a laser cutter, for instance) it doesn't matter much how the arm gets from one position to another, just that it does. I wonder, do we know whether there's comms back from the DSP board indicating 'done, end of movement' or does the calling software just wait for bit and assume?

Alan

I couldn't be bothered to fully reverse all the I/Os as it wasn't needed for my goal
of dumping the ISA PC and Win9x. However, from observations, I believe the
protocol is something like

Write : Move axis ? steps at speed ?
Read : Has axis ? finished?
If not finished goto Read

I know that large moves via my USB adapter are at full speed. However, initial
homing, where the software moves only one individual step at at time and then
checks the limit switch between each step are hampered by the overhead of
exception handling and USB transactions. Luckily, homing is the only time such
I/O intensive operations occur.




alanambrose

Re: Versatek - I think this is Versatek Systems Ltd which was dissolved in 2011. The main person seems to be Paul Mills based in Cumnor, Oxford.

Mike - is that the person you were in touch with once?

Alan

alanambrose

> The result being that...it effectively decouples us from relying on Win95 and
> old ISA motherboard machines?

Yes, totally.


The other key pathway that your work enables is to allow a port to OpenPnP. We would need to write a Cartesian to Scara axes mapping routine. That, almost certainly, means some cal routines to allow the conversion from nominal Scara position to calibrated Scara position. Again not such a big deal :)

Alan