Custom software for RV1S/RV4S

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

Previous topic - Next topic

arvydas

The original software RV1S came with is OK, but has it's own annoyances as most of you probably know. Primarily I'm a software developer and I'm very keen on building custom software for the machine. My biggest concern is that the full calibration method for the machine is unknown and I suspect I have calibration issues with my machine which make it quite complicated to use it.

Mechanically the machine is very simple, the arm movement can be controlled with some very simple inverse kinematics, image recognition for components/fiducials can be done with OpenCV. My only concern is communication with hardware. I can very easily sniff out the communication on COM ports, the imaging board should also be possible to hook into and get image data, but the ISA board is a complete mystery to me. Does anybody have any clue about the communication protocol with the ISA board? I've read somewhere in the forum that one of the members have reverse engineered the board and was wondering if there is any information about the communication that could be shared?

With currently available software libraries that cover gerber file reading, image recognition it should be possible to turn this machine back into a very usable tool with ability to recalibrate and utilize it to full potential.

Mike

User Jason here has been doing some reverse-engineering with the aim of getting it all working via USB - I think he said he'd looked at the ISA card stuff. It's been a while since I spoke to him. Probably worth sending him a PM. 

I'd be inclined to just replace the ISA card. All it does is generate step & direction pulses - I'm sure there must be some cheap/open source motion control solutions out there to do this. The ISA card is the only thing that ties the hardware to the old PC hardware, assuming you replace the video capture.

Although the machine is simple, I suspect the trick is in characterising the various mechanical imperfections, which is what I suspect the grid calibration is mostly about.

I'm fairly sure the calibration stuff can be worked out given  a little time and effort. We already know what the grid looks like (see drawings post in HW section), and I'm 99% sure there is no additional software involved. It would be way less work than rewriting the software!

Note that there are differences between the two circulating versions of the DLL that have some bearing on calibration. 
 


arvydas

RV software expects the ISA board to be directly accessible, wondering how Jason was planning on forcing the software to use different communication. If I remember correctly, ISA is addressed by referencing memory locations, but it's been a very long time ago since I looked into specs.

First thing that comes into my mind as a replacement for the ISA board could be something like RAMPS board. Very widely used in 3D printers to drive stepper motors, however not sure if the motors or the RV1S/RV4S could be driven by the board.

I think that any changes to the hardware which drives the machine would render the original software unusable as it's bound to hardware. Oh, if I could only get my hands on the source code for the RV software :)

Good point regarding imperfections in the hardware and as a result the requirement for the calibration grid. I might pursue this approach as I found bits of information in this forum regarding the requirements for the calibration jig and the position of the grid.

I'll see if Jason has any info.

Mike

The RAMPS appears to be a stepper driver - what you want is just something that generates the step/dir pulses. It would probably need to have some standalone motion control functionality as USB latency would be an issue. Although coordination between axes is less important than on a CNC.
The RV uses wierd 5-phase steppers so you'd want to retain the original driver/PSU box - no point in replacing that.


Jason

My goal has been to allow the existing s/w to work on a modern OS and PC
(like Win8.1 with no ISA bus, just USB).

The RV software suite is 32bit so, rather conveniently, will run on Windows 8.1
until it tries to access the hardware whereupon it issues IN and OUT x86
instructions which are privileged. These are not allowed in "user space" and
result in an exception and application termination.

So far, I have written an exception handler .dll which traps the privileged instruction
exception, examines the instruction which caused the exception to see if it's an
IN or OUT and translates it into a call to the FTDI MCU Host Bus Emulation API.
After the FTDI API call completes, the intruction pointer is incremented to hop over
the offending instruction and, in the case of an IN instruction the result is stashed
into the AX register and the handler returns "EXCEPTION_CONTINUE_EXECUTION".
This all seems to work OK. I also have a debug log so I can see the IN/OUT attempts
as RV place starts up.

I have an old ISA board which is awaiting hot-air removal of an edge connector
so I can wire the FT2232H mini module up to the RV ISA card via some appropriate
glue logic. I'm not sure what the impact of any latency in this system will be yet
but I'm hopeful it will be OK.

The other way of doing things would be to hook a couple of the functions in the
existing .dlls which do the IN and OUTs but I'm not sure I fully understand the
structure of the original .dlls as the developers used some Borland C++ compiler.
I guess it's not in the interest of any of the original RV developers to publish the
source otherwise it would be really easy to add the FTDI support and fix the silly
few bugs that we all know and hate.

I've also started writing a replacement for the ImageNation .dll which looks the
same to the RV software but actually captures from a standard Windows video
media device.

Once I have the ISA board connected (after I've completed a few outstanding
placement jobs) I will use the debug log and a few manual movements to work
out what the protocol is.
I'm sure someone with an ISA bus analyser could do this on a default hardware
setup but I don't have one.

I've also been toying with writing new software to help calibration but I think
that's a winter project... been having too much fun with summer holidays and
stuff :)

phonoplug

If this is of any help I'm not sure, but still.

The ISA card itself is nothing more than a tiny bit of logic and effectively two RS232 serial ports, though they do not appear on windows device manager. The DSP daughter cards however may well be quite clever. These all have an 8-bit connection into the ISA bus, and the output from them is 3 stepper signals, that go to each of the axis drives. I think thes 3 are 'step', 'direction', and 'power down' but I can check. I'm sure the DSP cards, one for each axis, take care of the accelerations and decelerations. I don't know whether its the PC or DSPs that work out the crazy geometry of turning arcs into square x-y locations. I suspect the PC does this.

The motors are all unusual 5-phase types, so your best bet would be to keep the drives with the motors. They were originally sold as matching pairs, and I think in general they are fairly good.

I'm vaguely aware of the guy that wrote the software on these machines. He only lives a few miles away from me. I have considered trying to get in contact with him in the past to see if he is open to the possibility of releasing the source code, if he even still has it. But then you would need the compiler too. Perhaps for a small amount of money he could be persuaded? He's got nothing to lose now.

Thoughts?

Mike

Quote from: phonoplug on August 20, 2015, 09:34:14 PM
I'm vaguely aware of the guy that wrote the software on these machines. He only lives a few miles away from me. I have considered trying to get in contact with him in the past to see if he is open to the possibility of releasing the source code, if he even still has it. But then you would need the compiler too. Perhaps for a small amount of money he could be persuaded? He's got nothing to lose now.

Thoughts?
FUCK YEAH!
Compilers can be got, languages can be learned.


Jason

I would be willing to chip in a small amount to be able to get the code released. Even if it wasn't fully open sourced and maybe some conditions attached, just so we could fix the really annoying things.

The geometry is all done in the PC software  (I've been disassembling the .dlls ;-)  )
I think the speed ramping is split between the PC software and the DSP.
The required turn distance and rate is sent to the DSP but I haven't captured the commands for this yet.

The serial ports don't appear on the device manager as it's not a ISA plug and play card and no driver is installed.
I don't think there are any interrupts either, it's all just polled.

EDIT: LOL Mike.
PS: I bet the code is fugly ;-)

Mike

The RV software is surprisingly good considering its age, but there are a few niggling issues that would be really good to fix, and probably not that hard - my list of most annoying issues would be :

Screen redraw issue - may be hard to find the root cause but could be possible to add a special button to kick it back into shape manually when it happens.

Add "Re-pick" option to the "edit CDF" prompt during run-time test.

Add an "Edit the CDF of the part you just failed to place" keyboard function. This may be as simple as setting the run-time test bit in the file.

Add native support for game joystick control, maybe also some keyboard shortcuts.

Allow feeder indexes to be specified in the CDF (Even if a hack like using special suffixes on the part name)

Quick "go to approximate feeder height" during feeder setup.

Key to do a few more retries (after you've made it across the room just in time for the last retry) 


phonoplug

The ISA card only uses /IOR /IOW and AEN control signals (not /MEMR or /MEMW, or any interrupts), the 8-bit data bus and address lines A0-2, A5-9.

Mike

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.

Mike

Quote from: Jason on August 20, 2015, 08:29:39 PM
I have an old ISA board which is awaiting hot-air removal of an edge connector
Hot air can be a bit dodgy with through-hole parts that aren't designed for reflow (see latest EEVBLOG video!) - for something big like an edge connector it would be pretty tricky.
I have a Metcal desoldering tool which may be a better bet - I'm sure I have some old MB's here, will have a look & see if I can pull a connector off intact.
Quote
The serial ports don't appear on the device manager as it's not a ISA plug and play card and no driver is installed.
The RVplace config file does appear to have COM port names, not looked in detail though.
A possible minor issue is USB latency from the limit switches when it does the arm reset, though it does do it pretty slowly, it could at least need the FTDI Latencytimer setting optimising.

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

I'd forgotten about that. I'll put a check in my exception handler .dll which looks
for the UART io address and, optionally, reroutes the data to/from the standard
Windows COM port API. This would allow use of FTDI or any other COM port.

Jason

Quote
Hot air can be a bit dodgy with through-hole parts that aren't designed for reflow (see latest EEVBLOG video!) - for something big like an edge connector it would be pretty tricky.
I have a Metcal desoldering tool which may be a better bet - I'm sure I have some old MB's here, will have a look & see if I can pull a connector off intact.
I was actually thinking about chucking the whole thing in the oven and then using tongs to remove the connector.
I'll vid it in case the whole thing goes up in flames ;-)

[/uote]
The RVplace config file does appear to have COM port names, not looked in detail though.
[/quote]
I don't think they're used. The exerciser programs DO use standard windows COM port API
but I think the UART access in RVplace is a hangover from DOS code and never got updated
to Windows API.

phonoplug