Messages

Just unscrew the activator from the lid and poke it into the switch sensor.
At least that is how mine was when I bought it

Just mentioning, nothing to do with me:

https://www.ebay.co.uk/itm/286074448497

I was bored tonight so I modelled some. I was in  a hurry so best check I've not messed and dimensions up.

[EDIT] It was late and there were a couple of mistakes. New upload attached:

A few more questions for Jason:
>>> I trap the priviliged instruction exception
This is using the windows DDK?

No, using a vectored exception handler which installs itself
when the substitute Imagenation DLL is loaded.

>>> I've written substitutes for the Imagenation .DLLs.
These are a straight C interface?

Yes.

>>> MPSSE
You got on OK with that? I found it an unreliable PITA.

I guess it may depend on which protocol you're using but in host bus emulation mode it seems OK.

Magnets cause tombstoning of some parts - need to increase height, maybe add provision for washer etc. for shielding

Maybe use smaller magnets arranged as a Halbach array so they have strong field on the underside only?

If anyone has a dire need for these in aluminium let me know as I can CNC them.

 Jason

What is the difference between RV1 and RV1s ? I thought it was something to
do with vision but the camera (4th photo) looks the same as on my 's' model.

Yeah, I think it stops the tape jumping around so much.

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.

>> 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.

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.

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. 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.

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.

I tried them a few years ago and I got a very bland reply back stating the card is obsolete.... useful eh?

Regardless, I have made progress.

I have compiled my own substitute versions of PXC2_95.dll and Frame_95.dll and managed to get RVPlace to link with them.
I needed to apply liberal amounts of IDA Pro and Ghidra to figure out exactly how RVplace links with them.
I popped some logging in each function and discovered the application only calls a small portion of the Imagenation API (see logs below)

I now have RVplace opening the demo job and placing it on Windows 10 64bit.
It obviously fails all the visioning checks because at the moment every frame/row returned to RVplace is full of black pixels.
Next job is to open a Windows capture device (Directshow API) and present real frames from that instead of blank ones.
I try it with one of the cheap USB  "EasyCap" composite video devices to start with. I'm not sure whether to expect any
aspect ratio issues (square vs non-square pixels etc).


Here are the logs from my substitue dlls as it made 3 attempts to vision the first component from the demo job:

DllMain : Process attach
PXC_OpenLibrary : iface=0x33b99ee ,size=0x138
AllocateFG
SetWidth : w=768
SetHeight : h=576
SetLeft : l=4
SetTop : t=0
SetXResolution : rez=768
SetYResolution : rez=576
AllocateBuffer : dx=768 dy=576 type=0x8
SetCamera : port=0 flags=0x0
Grab : flags=0x0
Grab : flags=0x0
SetCamera : port=0 flags=0x0
Grab : flags=0x0
Grab : flags=0x0
SetCamera : port=0 flags=0x0
Grab : flags=0x0
SetCamera : port=0 flags=0x0
Grab : flags=0x0
SetCamera : port=0 flags=0x0
Grab : flags=0x0
FreeFG
DllMain : Process detatch


DllMain : Process attach
FRAMELIB_OpenLibrary : iface=0x33b9b26 ,size=0x68
GetRow
GetRow
......
GetRow
GetRow
GetRow
FreeFrame
FRAMELIB_CloseLibrary
DllMain : Process detatch

There are two very different feeder types on the RV.
The earlier type uses two belts per lane and there is no per-lane tensioner. These I have found only work well for cardboard tape.
The later type uses one belt per lane and each lane has a spring loaded tensioner. These can work OK for thin plastic tape.