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.
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.
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.
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.
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 :)
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?
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.
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 ;-)
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)
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.
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.
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.
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.
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.
802-S-62-S-R from Toby might be a safer bet.
http://www.toby.co.uk/content/catalogue/products.aspx?series=802-S-xx-S-R
Quote from: Jason on August 21, 2015, 07:57:12 AM
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.
Although thinking about it, if you're talking to th ISA card you might just as well redirect the calls to the UARTs on the card...
I have seen a card without the UARTs though. May have been an early machine.
Wow, it's great to know that members have been doing quite some reverse engineering on the machine :) This is excellent news!
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?
I think that this should be our top priority. If you could get in contact with him and find out if he still has the source code and if he would be willing to share it for some fee or no fee at all would be fantastic. I would definitely chip in. Getting a compiler for the source code is easy.
If we could get the source code and understand how the machine works internally, then it opens up so many possibilities to fix the software and even modernize the hardware.
But if the source code for the software is no longer available, then we would need to pursue plan B which would be the reverse engineering of the ISA communication. I'll look into getting an ISA bus analyzer.
Ths ISA bus is simple and slow enough that any scope or logic analyser with enough channels would probably be adequate for analysis.
Maybe one of the cheap PC based LAs to allow logging.
However if Jason's method works, as it works at a low level it may not actually be necessary to understand the meaning of the conversation between the SW and the DSPs. It could just work!
I wonder if there is a disassembler (IDA Pro?) that supports the DSPs' instruiction set?
Quote from: phonoplug on August 20, 2015, 11:52:23 PM
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.
..and as the ISA card would be the only card in the "system" you could almost certainly hardwire most of the address pins - all the ones used to select the card within the ISA address space.
Any suggestions on a reasonably priced 16 channel logic analyzer? :)
I had a play with IDA Pro this morning. It provides a lot of information about the internals of the application, classes and methods. It should be possible to hook into the functions on a live machine and this way log the communication with the ISA board.
Quote from: arvydas on August 21, 2015, 04:40:00 PM
Any suggestions on a reasonably priced 16 channel logic analyzer? :)
Something like this perhaps ?
http://www.ebay.co.uk/itm/100MHz-16CH-250MHz-8CH-PC-USB-Logic-Analyzer-with-support-I2C-SPI-UART-and-PWM-/131452875075?hash=item1e9b33b143
AFAICS this isn't one of the saleae clones that expect you to steal the Saleae software to use.
Though that probably means flaky Chinese software, but you can hardly argue with the price.
Looks good. Will buy it as a last resort if I can't hook into the application which seems doable.
Going back to customer software, I was wondering whether an P&P module to extend
something like Meowcad could be an option (with RV support, of course!).
The RV export tools Mike and I did for Pcad and Eagle were what kicked off that idea
as I always thought it daft to have two different board databases.
Quote from: arvydas on August 21, 2015, 04:40:00 PM
Any suggestions on a reasonably priced 16 channel logic analyzer? :)
I've got the LeCroy Logic Studio box (software you can download free). I'm not entirely sure whether I want to lend it out, but conversely I don't know how much help I can offer as my skillset isn't in the domain of PC software. Hmmm. What would be involved, and how long would it likely take?
Quote from: phonoplug on August 23, 2015, 09:45:54 PM
I don't know how much help I can offer as my skillset isn't in the domain of PC software.
Contacting the software guy could potentially be more help than any logic analyser... ;)
Quote from: Mike on August 23, 2015, 11:56:46 PM
Quote from: phonoplug on August 23, 2015, 09:45:54 PM
I don't know how much help I can offer as my skillset isn't in the domain of PC software.
Contacting the software guy could potentially be more help than any logic analyser... ;)
I'll second that !
I can't help much programming wise, but I have a complete and working spare machine to play with that doesn't need to be placing chips if that helps.
Quote from: phonoplug on August 23, 2015, 09:45:54 PM
Quote from: arvydas on August 21, 2015, 04:40:00 PM
Any suggestions on a reasonably priced 16 channel logic analyzer? :)
I've got the LeCroy Logic Studio box (software you can download free). I'm not entirely sure whether I want to lend it out, but conversely I don't know how much help I can offer as my skillset isn't in the domain of PC software. Hmmm. What would be involved, and how long would it likely take?
It's difficult to tell at this point. I think that hooking into the application and logging all communication at the lowest level would beat any logic analyzer, because it's possible to get a lot more information about the application and it's states. I will let you know if my primary method of getting the communication protocol fails.
Quote from: arvydas on August 24, 2015, 09:58:40 AM
Quote from: phonoplug on August 23, 2015, 09:45:54 PM
Quote from: arvydas on August 21, 2015, 04:40:00 PM
Any suggestions on a reasonably priced 16 channel logic analyzer? :)
I've got the LeCroy Logic Studio box (software you can download free). I'm not entirely sure whether I want to lend it out, but conversely I don't know how much help I can offer as my skillset isn't in the domain of PC software. Hmmm. What would be involved, and how long would it likely take?
It's difficult to tell at this point. I think that hooking into the application and logging all communication at the lowest level would beat any logic analyzer, because it's possible to get a lot more information about the application and it's states. I will let you know if my primary method of getting the communication protocol fails.
Except that with a LA you can also probe the step/dir outputs so see the effect of the commands to it, and how things like ready/done type signals are implemented.
Made some good progress! It's just a start of course, but a very good start. The communication with the DSP board takes place in stepDsp.dll file. There are two functions that do the low level stuff:
Stepdsp::OutPort(int, uchar)
StepDsp::ReadPort(int)
As described by Jason, the addressing is done at lowest level with IN OUT assembly calls. This happens at addresses 0x00402F5B and 0x00402F84. The board is addressed over ports 0x300 - 0x303 and during initialization for the board, the application sends 0 to each port, then sends a sequence 0x80,0x40,0x0 for each port again.
When you click on the user controls for the machine to move by 1 to the right, the data sequence looks like this:
# right 1
OUT 302, 8A
OUT 302, 40
OUT 302, 0
OUT 302, 20
OUT 302, 10
OUT 302, 0
OUT 300, 80
OUT 300, 40
OUT 300, 0
OUT 300, 20
OUT 300, 10
OUT 300, 0
OUT 301, 80
OUT 301, 40
OUT 301, 0
OUT 301, 20
OUT 301, 10
OUT 301, 0
...
Didn't check the IN requests, but they should have ACK responses from the board. I suspect that 80-40-0 sequence is a deceleration for the DSP board which is handled automatically within software.
I'll write a proxy DLL for the stepDsp.dll so that I could log all interesting function calls in sequence and capture parameters. Then it's just a matter or playing around with the machine, capture the output and analyzing the communication. There are about 4 levels of abstraction within the machine and the one described above is the lowest level. There are classes to handle feeders, arm movement, nozzles, calibration, job processing, imaging and etc.
This opens up a huge amount of possibilities. For example, it should be possible to write a device driver for the DSP board, proxy the stepDsp.dll to another DLL and handle all communication with the DSP board via the driver this way making it possible to run the software on Windows XP and up. Alternatively it should be possible redirect all DSP board requests to a USB device as Jason planned, because all communication is a super basic direct addressing of IO ports.
I've read somewhere that DSP board has internal COM ports too? Does anybody have any info regarding them?
I'll keep updated with the progress.
I think the UART is just a couple of bog-standard PC UART chips at a standard address..
Quote from: arvydas on August 24, 2015, 01:36:14 PM
When you click on the user controls for the machine to move by 1 to the right, the data sequence looks like this:
yeah, remember that moving involves moving both cylindrical axis motors AND
rotating the head to maintain orientation of the part.
I suspect that each base address corresponds to one DSP.
302 being the X, 300 and 301 being Y and rotate (both with no movement in your test, so
no way to tell yet) and 303 being the Z which you never tested.
The commands are going to be speed, direction and number of steps. I think I did start
disassembling the calling functions which made it fairly clear but it was a while ago and I
just moved on.
With your hooking, I won't bother trying to capture any more, I'll concentrate on the
interfacing.
Do you have a way of generating compatible .dll functions? I assumed that GCC or
M$ C++ wouldn't be decorate the C++ the same as the Borland stuff.
Can't say I've looked close enough to notice, but does it actually make any attempt to keep the theta axis square when moving ? I can't see any reason to do this - all it needs to know is the delta between the start and end position (and ideally should get to the latter by the time it's at the end position, but without moving so fast the part slips).
If it is as simple as steps/direction/speed to each DSP, I wonder if instead of interfacing to the ISA card, it might be almost as easy to ditch the DSP card completely and just feed the trapped calls via USB into an MCU or small FPGA.
One nice thing about pick & place versus CNC is it's basically moving from one place to an other, and you don't really care about accurate speeds or co-ordination between axes.
I've been using IDA Pro and custom script I wrote to get the information without hooking as this was the fastest method. Seems that 303 is rotation address.
Attached debug log when rotating by 900. All numbers in hex.
OUT 303, 80
OUT 303, 40
OUT 303, 0
OUT 303, 20
OUT 303, 10
OUT 303, 0
OUT 303, 8a
OUT 303, 40
OUT 303, 0
OUT 303, 20
OUT 303, 10
OUT 303, 0
OUT 303, 84
OUT 303, 40
OUT 303, 0
OUT 303, 81
OUT 303, 4f
OUT 303, 0
OUT 303, 84
OUT 303, 40
OUT 303, 0
OUT 303, 89
OUT 303, 47
OUT 303, 0
OUT 303, 82
OUT 303, 40
OUT 303, 0
OUT 303, 83
OUT 303, 4d
OUT 303, 0
OUT 303, 84
OUT 303, 40
OUT 303, 0
OUT 303, 8a
OUT 303, 40
OUT 303, 0
OUT 303, 84
OUT 303, 46
OUT 303, 0
OUT 303, 80
OUT 303, 40
OUT 303, 0
OUT 303, 20
OUT 303, 10
OUT 303, 0
OUT 303, 81
OUT 303, 44
OUT 303, 0
IDA Pro is capable to generate readable reverse engineered pseudo code for all functions.
I've hit a road block with generating a proxy DLL. Win98 does not want to load rvplace.exe and it complains that it can't find the exported functions even though dumpbin shows them correctly. The proxy DLL loads just fine with rvplace.exe on Win XP and up. Tried to compile the DLL with VC6 and MSVS2005 on Win98, XP and 7, but I end up getting the same error message.
I'm using genwrapper which you can find here: https://github.com/floodyberry/genwrapper and you can find more details about the implementation here: https://floodyberry.wordpress.com/2008/09/08/generating-dll-wrappers/
However, it generates incorrect def file that needs fixing in order to compile. LMK if any of you would be interested to have a look at the implementation and I'll upload the source code I currently have. My first step was to generate a basic DLL that forwards all functions and gets loaded by rvplace.
My next step to solve this is to inject a DLL in to rvplace.exe process and hook functions dynamically. This way I should be able to hook any function within rvplace.exe and any library it loads without the need to create a proxy DLL. This is somewhat a challenge as hooking functions in Win 98 is very different than hooking on NT based Win version with CreateRemoteThread, however I'm sure I will be able to solve it. Just need to get the basic Hello World thing going with injector and injectable DLL :-)
That looks like it's shifting nibbles of data at a time . If you read the right-hand digits vertically they are always in pairs.
Top 4 bits are probably commands, with the bottom 4 as parameters :
Bit 7 : write MSnibble
Bit 6 : write LSnibble
I wonder if something from these guys would fit the bill:
http://www.planet-cnc.com/index.php?page=home
should interface straight into the stepper drivers?
Phonoplug, did you manage to contact the software guy?
Hows this negotiation working out ?
sarason
>>> That looks like it's shifting nibbles of data at a time
Ah v good, I just twigged yesterday that the card is an 8-bit ISA card - so that makes sense. Also, I just noticed this:
http://anagram.net/nuts/Versatronics/Contents%20of%20ramp%20dot%20sys.png (http://anagram.net/nuts/Versatronics/Contents%20of%20ramp%20dot%20sys.png)
Alan
>>> I've hit a road block with generating a proxy DLL. Win98 does not want to load rvplace.exe and it complains that it can't find the exported functions even though dumpbin shows them correctly. The proxy DLL loads just fine with rvplace.exe on Win XP and up. Tried to compile the DLL with VC6 and MSVS2005 on Win98, XP and 7, but I end up getting the same error message.
I know this is an old thread, but I see the apps were originally compiled with Borland 5.02. There's one class in stepDsp.dll (exports below) - so it was probably at least part caused by Borland C++ name mangling vs. Msft mangling.
A.
LIBRARY STEPDSP.DLL
EXPORTS
@Stepdsp@$bctr$qipcp6Speeds @14 ; Stepdsp::Stepdsp(int,char*,Speeds*)
@Stepdsp@$bdtr$qv @16 ; Stepdsp::~Stepdsp()
@Stepdsp@CalcMoveTime$quii @2 ; Stepdsp::CalcMoveTime(unsigned int,int)
@Stepdsp@CalcProcTime$qui @12 ; Stepdsp::CalcProcTime(unsigned int)
@Stepdsp@CalcRampTime$qui @11 ; Stepdsp::CalcRampTime(unsigned int)
@Stepdsp@CalcSpeedTime$quii @13 ; Stepdsp::CalcSpeedTime(unsigned int,int)
@Stepdsp@CalculateRamp$qui @3 ; Stepdsp::CalculateRamp(unsigned int)
@Stepdsp@GearAxis$qii @10 ; Stepdsp::GearAxis(int,int)
@Stepdsp@GetByte$qi @45 ; Stepdsp::GetByte(int)
@Stepdsp@GetErrorStatus$qi @26 ; Stepdsp::GetErrorStatus(int)
@Stepdsp@GetMoveStatus$qi @47 ; Stepdsp::GetMoveStatus(int)
@Stepdsp@GetPos$qi @21 ; Stepdsp::GetPos(int)
@Stepdsp@GetResetStatus$qv @35 ; Stepdsp::GetResetStatus()
@Stepdsp@GetStatus$qi @25 ; Stepdsp::GetStatus(int)
@Stepdsp@Init$qv @18 ; Stepdsp::Init()
@Stepdsp@InitAxis$qi @19 ; Stepdsp::InitAxis(int)
@Stepdsp@InitXY$qlluiii @28 ; Stepdsp::InitXY(long,long,unsigned int,int,int)
@Stepdsp@LoadCode$qv @17 ; Stepdsp::LoadCode()
@Stepdsp@LoadRamp$qv @15 ; Stepdsp::LoadRamp()
@Stepdsp@ModifySpeed$qii @8 ; Stepdsp::ModifySpeed(int,int)
@Stepdsp@MotorOff$qi @23 ; Stepdsp::MotorOff(int)
@Stepdsp@MoveAxis$qiluii @31 ; Stepdsp::MoveAxis(int,long,unsigned int,int)
@Stepdsp@MoveAxis1$qiluii @5 ; Stepdsp::MoveAxis1(int,long,unsigned int,int)
@Stepdsp@MoveAxisRel$qiluii @32 ; Stepdsp::MoveAxisRel(int,long,unsigned int,int)
@Stepdsp@MoveAxisRel1$qiluii @6 ; Stepdsp::MoveAxisRel1(int,long,unsigned int,int)
@Stepdsp@MoveXY$qlluii @29 ; Stepdsp::MoveXY(long,long,unsigned int,int)
@Stepdsp@MoveXY1$qlluii @1 ; Stepdsp::MoveXY1(long,long,unsigned int,int)
@Stepdsp@OutPort$qiuc @50 ; Stepdsp::OutPort(int,unsigned char)
@Stepdsp@Read$qi @42 ; Stepdsp::Read(int)
@Stepdsp@ReadAck1$qi @43 ; Stepdsp::ReadAck1(int)
@Stepdsp@ReadAck2$qi @44 ; Stepdsp::ReadAck2(int)
@Stepdsp@ReadPort$qi @51 ; Stepdsp::ReadPort(int)
@Stepdsp@ResetCard$qv @27 ; Stepdsp::ResetCard()
@Stepdsp@RingBack$qiuc @33 ; Stepdsp::RingBack(int,unsigned char)
@Stepdsp@RingBackOut$qiiuc @34 ; Stepdsp::RingBackOut(int,int,unsigned char)
@Stepdsp@SendByte$qiuc @39 ; Stepdsp::SendByte(int,unsigned char)
@Stepdsp@SendMaster$qiuiiuiuii @4 ; Stepdsp::SendMaster(int,unsigned int,int,unsigned int,unsigned int,int)
@Stepdsp@SendSlave$qiii @7 ; Stepdsp::SendSlave(int,int,int)
@Stepdsp@SetBreakPoint$qii @9 ; Stepdsp::SetBreakPoint(int,int)
@Stepdsp@SetDirection$qii @22 ; Stepdsp::SetDirection(int,int)
@Stepdsp@SetPos$qil @20 ; Stepdsp::SetPos(int,long)
@Stepdsp@SetResetStatus$qv @36 ; Stepdsp::SetResetStatus()
@Stepdsp@SetStatus$qii @24 ; Stepdsp::SetStatus(int,int)
@Stepdsp@StartXY$qv @30 ; Stepdsp::StartXY()
@Stepdsp@WaitBP$qi @49 ; Stepdsp::WaitBP(int)
@Stepdsp@WaitNotBusy$qi @38 ; Stepdsp::WaitNotBusy(int)
@Stepdsp@WaitNotSame$qiuc @46 ; Stepdsp::WaitNotSame(int,unsigned char)
@Stepdsp@WaitSame$qiuc @48 ; Stepdsp::WaitSame(int,unsigned char)
@Stepdsp@Write$qiuc @37 ; Stepdsp::Write(int,unsigned char)
@Stepdsp@WriteAck1$qi @40 ; Stepdsp::WriteAck1(int)
@Stepdsp@WriteAck2$qi @41 ; Stepdsp::WriteAck2(int)
Hello,
has something come out here after 5 years?
I like the software and hardware of the RV4s quite well and I would like to use them for years to come.
But as I get more and more hardware problems I am looking for an alternative in parallel.
I would prefer to only replace the hardware, but if necessary, I also change everything.
If someone needs help to get ahead, that's not a problem.
I would like to use my machine for a long time!
I know openPNP with GRBL motor drivers.
Logically, you can't just exchange them.
But maybe there is something already in that direction?
Has anyone done anything with it?
Quote from: dirk1980 on July 20, 2020, 04:58:06 PM
Hello,
has something come out here after 5 years?
I like the software and hardware of the RV4s quite well and I would like to use them for years to come.
But as I get more and more hardware problems I am looking for an alternative in parallel.
I would prefer to only replace the hardware, but if necessary, I also change everything.
If someone needs help to get ahead, that's not a problem.
I would like to use my machine for a long time!
I know openPNP with GRBL motor drivers.
Logically, you can't just exchange them.
But maybe there is something already in that direction?
Has anyone done anything with it?
If your hardware dies, it seems pretty likely the future is full of those Chinese P&Ps, in many ways the vision equipped ones are better than an RV but the software seems to be pretty horrid and makes you walk through even more hoops than Versatronics does. However there are already considerably more of them out there than there are RVs and there do seem to be whispers of OpenPnP efforts on some of those, many hands make light work and all that - plus the chinese software might catch up.
Moving your data out of an RV isn't really a huge issue. Pretty much all machines basically take the same XYR data you probably started with (or you can extract it from the TFR file) and store it in fairly simple formats. The only things you have to recreate from scratch are package definitions.
Some of the Chinese P & Ps may not be bad, but I want something that you can fix yourself.
I think most of the problems come from the old PC, ISA are dying out and Win98 has long been outdated.
And if a solution has been found here in the meantime, that would be great.
If I knew what happened in the individual modules and how they work together, I could perhaps help to replace parts.
What does the head/arm controller do? 12 & 9V, relay control and ?
Does anyone have information about the protokoll?
The hardware in the feeders is quite simple and can easily be updated on something new.
The connection of alternate feeders should also not be a problem.
Other software and controls would be an alternative.
But nothing that can be easily exchanged, except the PCB data.
I got armtest.exe and rvplace.exe controlling RV hardware Windows 10 64-bit
via my USB to ISA adapter.
rvplace will perform the initial homing and then perform the warmup 8)
However, I now have to do something about image grabbing.
Would anyone happen to have archived pxc_15.exe from the Imagenation
support site? This was a Win64 release of drivers according to this:
https://web.archive.org/web/20150612101854/http://www.imagenation.com/dnpages/pxc_files.html
Perhaps an email to CSsupport@cyberoptics.com ?
Steve.
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
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.
This is very clever stuff, well done.
Trev
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.
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.
Well done, this is impressive.
Trev
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.
I have heard it's for the Q Placer. No good for RV1s or RV4S but it did use the same feeders.
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
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.
>>> 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 (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
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
>> 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.
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.
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
> 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
I think an OpenPnp port would be a massive job - apart from the peculiarities of the Scara geometry itself, you also have to deal with the situations where a move needs to be split into multiple moves as there are reachable positions that can't be moved between in a straight line.
Can Openpnp even deal with a non-rectangular working area?
Then you have to deal with the fact that the relationship between the fid cam and nozzle is different at different locations.
And figure out how to manage all the grid calibration stuff.
And figure out the maximum reliable speeds and timings for the various permutations of moves
And the tool loading sequences.
What would be the actual benefit ? The machine isn't going to end up any more accurate or faster.
Although the current software has its quirks and annoyances, none are show-stopping- I don't recall ever having any software issues which have resulted in ruined boards or significant lost parts, for example.
That's a definite 'no' vote from you then :)
Did you ever communicate with Paul Mills, if not I thought I might write him a polite letter from his RV fans?
Alan
No.
OK I'll contact him and I may well run the text by you guys beforehand. I'm well off-thread so I should bring us back:
A few more questions for Jason:
>>> I trap the priviliged instruction exception
This is using the windows DDK?
>>>
Write : Move axis ? steps at speed ?
Read : Has axis ? finished?
If not finished goto Read
<<<
Ah good, so it's 'exec command and wait'.
>>> I've written substitutes for the Imagenation .DLLs.
These are a straight C interface?
>>> My RV1S has UARTS on the ISA card
From memory mine uses the PC's com ports although it's been a while since I thought about it and my RV is in a different location so I can't check atm.
>>> MPSSE
You got on OK with that? I found it an unreliable PITA.
Anyway, great work Jason, I'm sure you have our support. Is there anything we can help with?
Alan
Quote from: alanambrose on May 21, 2021, 04:31:20 PMA 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.
Quote from: alanambrose on May 21, 2021, 04:31:20 PM>>> I've written substitutes for the Imagenation .DLLs.
These are a straight C interface?
Yes.
Quote from: alanambrose on May 21, 2021, 04:31:20 PM>>> 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.