Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Simon0362 on March 16, 2013, 06:24:42 AM
-
Hi,
I am using the simple threading wizard to try and cut a 32 x 1.5mm thread on my Emco Compact 5PC (modified to Mach 3).
I have had a number of problems that appeared to be associated with the X infeed missing steps. When running the code generated by the wizard, I can hear the X attempt to get close to the thread OD then there are a couple of missing step sounds and then the thread is cut at an indeterminate depth.
Looking through the generated code based around G76, it appears to be in line with what I was expecting:
G00 X22
G00 Z3
G00 X16
M03 S200
G76 X13.9 Z-16.5 Q10 P1.5 J0.05 L45 H0.05 I29 C6 B0.025 T0
I have tried to read all of the threads (sorry ;D ) but there appear to be none with similar problems.
I then edited M1076 to give me the full code and that is where I start to see what may be a problem - but no idea why:
(Min decremant being used)
(Decrement = 0.05 pass 2)
G01 Z3
G32 X15.9 Z2.9446 F1.5
G32 X15.9 Z-16.3125 F1.5
G01 X22 Z-16.5 F1.5
G00 X22 Z3
G00 X16
The underlined G32 is the key issue I think; Z is set to 3 followed by an instruction to screwcut to 2.9446, followed swiftly afterwards by the 'real' G32 to do the thread I need.
So.....:
- what am I doing wrong.....? Is this something I have set/not set in the wizard or is this something that is caused by 'something' else?
If I edit out the 'odd' line, then the threading is successful.
Both files attached in full in case there is something else buried in the files.
Rev is 043.062, using MSM v2.0 and the wizard is shown as 1.7
I know that threading is always a difficult issue but this has me very confused.
Simon
-
Dont see why that would cause an issue, maybe try your start further away, say Z10 and see if that helps.
Can you attach your xml if that doesnt help
Hood
-
Simon,
I don't use MSM and there are posts that 062 has problems. So not sure where the culprit may be.
I never had problems with using either the M1076 for output based on G76 or G32 and frankly only modify the M1076 for G32 output and nothing else.
One thing that a user should do is always click the button, in the wizard , check the "calc number of passes" as that will tell one if the acceration or velocity exceeds
user configuration based on selected rpm. Not sure what MSM does.
RICH
-
Per Hood's reply, the start should be 3 to 5 pitch lengths away (general rule of thumb) and there is nothing wrong with it even being longer.
RICH
-
Hood, Rich, thanks for your responses.
Rich, I couldn't find anything about 062 issues on threading - but I am probably not looking hard enough...
My biggest issue at the moment, and the thing that I think is causing he problem is the snipped bit of code in my first post which contains TWO G32s, one directly after the other.
I understand that G32 requires a move to X and Z prior to the G32 itself
The output from the wizard gives a Z move followed by an initial G32 going all of 0.05mm fixing X I guess, then the proper G32.
I feel my lathe cannot cope with the initial G32 followed by the 2nd one
Or am I barking up he wrong tree....?
Simon
I also tried setting the Z much further away initially with the settings (Z clearance) which didn't seem to do anything and then directly moving the start to Z to 10.
-
Can you attach your xml and I will take a look and see if there is an issue in it.
Hood
-
Hood,
Sorry for the delay, external pressures pushing me away from playing with my toys!
XML attached for you to look through.
Further information:
Without going through the entire sequence, I have ended up hand coding a very simple G32 script - as below
G0 X2 Z22 (start point)
F50 (set feed rate)
G1 X0 (advance to the thread point at X=0)
G32 X0 Z0 F1.5 (Thread without changing X, to Z at 0 so 22 long and a pitch of 1.5mm)
G1 X2 (retract to X=2 at the end of the thread)
G0 X2 Z22 (return to start again)
I then copy/pasted a number of these into a file and inserted an M1 just before each G32.
Running the program lets the lathe cycle through over and over until some indeterminate point when the G32 results in a sound of steppers jumping, the DROs showing X at 0 and Z at about 0.5.
The program then stops several lines later, usually at the G1 X0 point and the program halts with the Run button flashing.
So completely mystified, the normal G0 and G1 cycles work perfectly happily and accurately but this entire threading cycle is driving me nuts!
Any thoughts gladly received.......
Simon
EDIT:
Forgot to say that I had a storage scope onto the index pulse and it is solid and clean...
-
Config menu, Ports and Pins, Spindle Setup, you have Use Feedback in Sync mode disabled.
Hood
-
Sorry, wrong .xml - for some reason the 'current' one does not have the same name as the launcher. This one is *really* the current one, updated as of yesterday according to the file.
Simon
-
You have an Index Debounce of 100, I suspect that wont be helping, try it at 0.
Hood
-
which version of mach3 do you have by the way? I had a similar problem and i corrected it by changing version..thanks
-
Hood, I have had various values of Index debounce and I am now back at 0 - nothing makes any difference!
Valmet, I was originally on 062 then I saw another recent thread which suggested that 066 would fix it and also rolling back to 057. None of them appear to make any difference. 058 caused an immediate exit of Mach, 059 would not go past the PP driver install.
Which version are you running?
However I have noted some more curious details also consistent with the change log which mentions 'correcting incorrect parameters being transferred in threading'
My little program which starts at x=0, z=30 and threads to z=0, retracts, g0 to z=0, shows some intersting points when running according to the screen:
Retract which should run at g1 speed appears to be much faster (g1speed set to 40mm/min), the g0 return is running at 400 and not the normal 500 and the return to x=0 g1 speed shows as 31 to 32...
Looking through lasterrors shows that (as I understand it) there are several successful threads cut at 1.5mm pitch, calculated as 350mm/ min, however there are also calculations where the pitch is taken as 50mm and a fail follows. This just happens to be the feedrate associated with the next command. Change that to say 44 and the erroneous pitch follows it.
Happy to hear more suggestions but this is looking like a case of a problem with g32 and the parameters passed to it at some point.
Thoughts anyone...?
Simon
-
Is the active state of your Index correct? You have it set active low and normally I would expect it active high but suppose that depends what you have connected.
I dont use the parallel port for any machines but I have not seen anyone else reporting the issues you are so if there is a bug it must be something in your setup that is bringing it to the fore, what I have no idea yet.
Will keep looking at your xml and see if I can find something but could you confirm that the index LED is only n when the index pulse is being sent.
Hood
-
Hood, thanks for keeping up the hunt!
I can confirm that I have a low going pulse - I have a scope looking directly at the cable as I write this
Simon
-
Would it be possible for you to make a new xml just with the basics and see if it exhibits the same issues? Should really only need axes and index enabled as a test.
Hood
-
Yes, I will do that tomorrow. My first attempt tonight resulted in lots of problems so I will try with a clear head tomorrow.
Simon
-
Also attaching my lasterrors and gcode files - I thought I had attached them before but... ???
-
Hood,
Eventually made a new xml and I have just confirmed exactly the same issue with this version...
Thanks for looking,
Simon
-
Looked through the xml and I dont see any issues so not sure whats going on. I dont think I can realy test out here as I dont think the problem can be seen whilst simulating as if I recall the motor just stalls?
Can you try in Dia mode rather than Rad mode?
Have you tried with a standard lathe screenset? Dont see how it could affect things but worth a try.
Hood
-
Hunt,
Looked through the xml and I dont see any issues so not sure whats going on
"You are not the only one.....!" ???
I tried with the standard screenset - have to say I found it really clunky but it did exactly the same thing.
I also tried with the on board PP just in case it was something to do with the 2 parallel port cards I have installed to operate the mill and lathe - same issue.
I then tried something that seems to help but does not cure the problem - I changed the setting for LookAhead from 20 down to 1 - this causes the errors in the feedrates to go away but the G32 problem still exists.
To recap, since I think there is a danger of my base problem being buried:
when I run a simple 'G32, retract, return Z, return X' code, on some occasions the script _initiates the G32 and then jumps through to the end of the return X, without moving the axes other than a microscopic amount. The DROs however move normally with Z moving from the start at 30 to between 27 and 25, X sometimes moves from the start 0 to 0.3 or so, but not on every occasion.
Points to note are that the G32, retract, return Z, return X are ALL apparently executed - as far as Mach 3 is concerned anyway. It seems to me that Mach suffers a problem with the G32 which causes it to leap through code until it hits a firm stop - an M1 in this case.
Furthermore (when LookAhead is set to 20), the feed rates for the G0 and G1 moves are not those that are set - G0 runs at 400 (I think) and the final G1 to return X to the start is defined at 40 ans actually runs at 33 mm/min. Change the lookahead parameter to 1 and this problem goes away - perhaps linked, perhaps not.
Searching through other threads including another recent one you had commented on, suggests the use of the LastErrors file - this (see my upload earlier) generally shows the threading calculation correctly as a 1.5mm pitch screw, needing 350 mm/min on Z. The failing runs show that the thread pitch to be 40mm, needing 11000 or so mm/min.
One other point is that I see a recent version of Mach (066 I think) has 'incorrect transfer of parameters for threading' as one of the bug fixes - is it possible that this bug is not acttually fixed?
So my own conclusion is that the problem is not a setup issue (as you say, the xml seems ok), but a bug buried in Mach. Maybe it is exacerbated by my setup but I am unable to understand how Mach thinks it has done 4 lines of code successfully when the DROs are not where the program says they should be and when 2 of those 4 lines take a visible finite time to execute.
It is as if Mach has upped the pulse rate to many times higher than it should be.....
So that you can see the problem, I shot this wobbly video on my phone - so sound/picture quality are not good) http://youtu.be/wMDoSYNnRcM (http://youtu.be/wMDoSYNnRcM) but you get the general idea - the only fail that I shot was the first run though.
Almost final question - is there a diagnostic file I can look through to see what Mach *thinks* it has told the PP to do - and what frequency it did it at....or anything else I can look through to pin this problem down?
And finally, if this is a genuine bug, is there somewhere where I can report it as such??
-
I have notifications on for this thread and notes of this being a potential bug. The more we know, the more likely we can get it sorted.
Brett
-
Hi all,
Simon0362 in your video the Speed DRO is at zero rpm.
Maybe I am wrong, but I think you have to code a speed for threading
( S230) in your case.
just a thought
Alex
-
As Alex says unless you have told Mach the spindle is running then things will not work correctly. Doesnt matter if the spindle is running as in your video as you have not told Mach the spindle is running with a M3/M4.
Hood
-
Guys,
Thanks for the observation but I do tell Mach that the spindle is running - in the short gcode program, there is a M3 almost at the start. I also force a M3 manually as well at times, in fact I think the G32 will not run at all if there is no M3.
However I agree that I have not instructed a speed but I understood that this was not necessary since Mach is only concerned with index pulses for threading and derives the spindle speed from that.
Nonetheless I will give it a try later on tonight.
Simon
-
I didnt see a M3 in that code you had on the screen and if there had been the spindle speed should have been in the DRO. If you had told Mach the spindle was running then there is a problem somewhere as you are not getting the RPM showing.
Hood
-
My apologies, I just looked at your xml again and used the standard lathe screen and I see the Spindle true DRO is above where I thought the spindle RPM should be. Like you I dont like the standard screen so never use it. I see your spindle rpm was indeed showing there, again apologies.
Hood
-
No problems -this is the first time I have used the standard screens and had to hunt each item down as well, nothing was where I was expecting it to be!
-
Confirmed that including the S parameter to define the speed is not needed - I added S230 to the M3 in the program and it failed first time!
I have also run the driver tests - and almost thought I had found the problem since the initial message as it started was 'pulsing too fast' ...however this almost instantly cleared and I had a stead almost completely clean line with an occasional short spike. The program f_inished successfully, so I ran it a second time to see if I could see anything on the data appearing on the screen that was of any significance - and couldn't see anything. The 2nd pass was fine too.
I looked closely at the gcode(which was edited from the original 'extended, verbose' G76 file) and remarked out a G49 that seems to have no meaning(odd....).
I then reran the video - well my iPhone - for another hopefully less crappy run. http://youtu.be/xcP9VJCs--M (http://youtu.be/xcP9VJCs--M)
This shows the standard fail again, on the MSM screens which I find easier to view and use.
It also shows another issue which I have only seen twice before I think. The usual problem happens but the Z continues to advance at a g l a c i a l pace - the feedrate shows flashes of 5-10mm/min (when it should be 350) and eventually reaches the end point after which, all of the other movements are at a similar pace - I timed one cycle and it took about 16 mins rather than the normal 16 or so seconds.
I checked the index and it is still there happily pulsing away!
This was the point I ran the driver test to see if there was some weird clock instability.
Brett, good to know that someone is looking at the issue, let me know if there is anything else that I can look at or test to help clarify - I think I am at the limit of checking my own systems though - and most of this system also drives my mill and has run multi thousand line programs lasting for up to around 2 hours without any problems (apart from operator induced ones!).
Simon
-
Did you try in Dia mode?
-
Also G49, dont think I have ever seen the wizard produce that in the threading code, will have to go and have a look.
Hood
-
Nope tried with my profile, your profile, Test= false, test=true and definitely no G49 here.
Is this the simple threading wizard you are using?
Hood
-
Hi,
tested some things. Unfortunately can not make a real test because the lathe is disassembled in the moment. This is what I tested using version .062
Created a Brain that gives me an index pulse. Then loaded the XML from Simon and the G code an run it. Everything looks like I expected it. The code
was running without problems. After a couple of hours testing I decided to wire an index sensor to the PP to see if that makes a difference.
Its also running fine here, so far as I can say.
Alex
-
Hi,
Sorry for the delays but work and home life can get in the way of my hobbies!
- Hood, you are quite right, I tracked down which gcode program I used as a basis and it turned out to be the taper turning wizard - so that contains a G49 in the header - whatever it does. Sorry, but my slightly disjointed investigation leads to some blind alleys
- Alex, thanks for trying, I wonder whether the PP is part of the issue which I assume is not emulated in the Brain
- Hood, no I had forgotten about diameter mode testing - however I have just tried it and exactly the same problem happens
Is there any way that I can dump the output to a file rather than to the parallel port?
Is there any other form of diagnostics that I can run in parallel or run after the fail?
Any thoughts about the very slow activity seen towards the end of my second video?
Any other suggestions....
Simon
-
I think Art is the only one that will be able to see where your problem is as he is the guy that does the driver and as far as I know that is where the threading is done in Mach when using the parallel port.
In previous versions Art wrote a plugin so that he could see what was happening on the systems of the people that were helping with the tests, this however, as far as I understand, is no longer any use as the driver has been updated since.
Maybe Brett will see if Art will chime in, if not I will skype him and ask him if he can look.
Hood
-
Hi Guys:
The best way to tell as I recall, is to select the "Debug" option in the configuration, then try one line of threading. Stop the program and look in the LastErrors.txt fille in the mach3 folder. Post it here if you like, it tells you whats going on during the thread, and why it might fail..
Art
-
Art,
Thanks for getting involved.
I did as you suggested and set the debug flag:
3 files attached, the first one (run1) had one successful pass followed immediately by a failure. The second file (run2) had a number of successful runs followed by a failure at the very end. Gcode attached for reference.
Additional information summarised from the previous mails:
* the retract at G1 at the end of the thread run 'appears' to run much faster than programmed (difficult to tell over 2mm)
* the G0 rewind runs at 400 and not the maximum 500mm/min
* the G1 return X to the start position runs at an indicated 32-33mm/min rather than the variously programmed feed rates around 40mm/min
* in all cases when the run fails, there is a calculation for threading that appears to use a pitch of 40mm rather than the requested 1.5mm - which would require a very significantly faster feedrate.
Open to further requests for making tests.
Simon
-
Simon0362,
Have you contacted Calypso about this problem?
- I don't use MSM and don't know what version of Mach they want installed with MSM
- I am not sure that you want to change between screens when using MSM as that could / may create problems
- Do you have both MSM and Mach installed together on the same drive? Ask Calypso if that could create problems.
So my first concern in addressing your problem is that your using MSM and that in itself could be a culprit.
Later,
RICH
-
Rich,
I haven't contacted them but I did try using the standard turn screens because I had similar screens. However they produced the same problems - see the first video I uploaded to youtube...
Not sure what you mean by "changing between screens" -if you mean when running, I don't usually touch the UI whilst a program is running.
Msm and Mach are installed on he same drive, but this is their standard practise, I believe.
From their website:
Mach3 3.43.62 - This is the current CVI recommended Mach vrersion for MSM Turn and Mill-Turn use. It is also working well for Mill use, though it has less field test time than 3.43.37 at this point in time.
This is the version which CVI previously recommended for use with MachStdMill Turn and Mill-Turn. Earlier Mach releases between 3.43.38 and 3.43.62 each have a significant flaw wrt to some aspect of lathe operations.
Mach3 3.43.66 - This Mach release fixes a few more Mach lathe related bugs and is required for some lathe features that were introduced in MSM 2.0.4.2 beta. Without at least this Mach version, the new features (e.g. Front/rear tool post editing) will not appear in MSM (See the MSM releae notes for more information).
This is the version which CVI currently recommends for use with MachStdMill.
As I said, I did test with the standard screens but went back to MSM since I am used to them.
Meant to say I have tried 062, 066 and currently 067
Simon
-
Simon:
I cant tell exactly whats wrong. The numbers dont look particularly bad. They show a slowdown of about 20% during the cut.
Its been awhile since Ive odne any threading work, couple years anyway, so Im not fully up to snuff of the readings.
I dont like that the adder value is always zero, but that may be normal in that driver. The adder controls the speed. The error
controls the adder. Mach3 purposely increases planned speed by 20% so the thread shoudl immediately drop that speed by 20% when the thread starts, thus
giving the right speed, and allowing it to speed up by at most 20% if the spindle speed should increase. ( yours doesnt increase so thats not an issue).
The reading of pitch of 40 is simply the G1 or G0 at th end of the thread and as a result shows no threading run vaues after the report. ( Thats normal
in other words..).
Thu - 11:07:22 ---Spindle Lock: 5220 , Total Ints: 0, Total Spindle Ints: 0, Error: 811, Adder: 0 LastRot: 6489
Thu - 11:07:22 ---Spindle Lock: 5220 , Total Ints: 5765, Total Spindle Ints: 5220, Error: 545, Adder: 0 LastRot: 6587
Thu - 11:07:22 ---Spindle Lock: 5220 , Total Ints: 11711, Total Spindle Ints: 10440, Error: 1271, Adder: 0 LastRot: 6481
Thu - 11:07:22 ---Spindle Lock: 5220 , Total Ints: 16977, Total Spindle Ints: 15660, Error: 1317, Adder: 0 LastRot: 6549
Thu - 11:07:22 ---Spindle Lock: 5220 , Total Ints: 22206, Total Spindle Ints: 20880, Error: 1326, Adder: 0 LastRot: 6544
The spindle Lock is the spindle speed in interrupts just before the threading begins. The error is the difference it saw
in the last rotation. The resport of a large pitch you can ignore, its just a false report based on the G1 motions post
threading. The Adder is the only value I dont like, but I cant recall if thats normal or not.
Be nice to know if anyone using threading gets an adder value in that test, I simply cant recall. The readings other than
that though, show no failure at all. They seem to track, the errors are what Id expect from a proper thread and they dont
seem to grow meaning the variations appear to be properly dealt with.
Im assuming you have "Use Actual Spindle Speed" checked in the config?
Art
-
I just read the entire thread to see if it helps..
>> I can hear the X attempt to get close to the thread OD then there are a couple of missing step sounds
THAT sounds like the error. Mach will not know if steps are lost, so the failure may be lost steps beacuse the
X motor stalled. Do you have a way to tell if the emco has lost a few steps. Zero to a known and repeatable spot,
after a filure use a G1 X..Z.. to go back to that spot. Is it off position...if so, thats the problem, we need to figure out why its
lsoing spot. That double G32 HAS to go, two G32's in a row will not reset the WaitForTrigger, there always has to be a G0 or a G1 after a G32, preferable a G0.. ( which cancels threading mode so another can be mode switch can occur. ). SO ensure nowehre is there
two G32's in a row.. that will always fail in one way or another.
Art
-
Hi Guys,
just some thoughts.
i don't think a stalling stepper is the problem since the G Code is stopping at that moment.
As I posted before I did some test ( .062 ) everything is well here.
Some things I found while testing.
The pulse must com in clean and stable. That means the Speed should be as stiff as possible.
The feedrate during threading should be not more then 75% of rapid traverse.
The G0 feedrate will not reach 100% after the G32 command unless there is at least a G4P0 command after G32
this does not affect a successful thread.
Feed Override must be 100% ( feed override is not disabled)
I think the index pulse is not coming in clean or there is a hardware conflict or whatever affect the pulse.
just a thought and may be wrong.
BTW is it possible to stop Mach writing to the LastErrors.txt file at least during threading ?
Regards
Alex
-
Art, Alex,
Let me try and deal with each point in turn since this problem has evolved since my original plea for help:
- Alex is right, the ''chirp' is not visible on the lathe - I have had a DTI on both axes and the error consistently manifests itself as a stop during or after the G32 with the Z axis usually showing about 27 (Z runs from 30 to zero) and there is no movement of either axis. If you have the chance, you can see it happen on one of the first runs on each of the YouTube vids I posted
- double G32 - this is the output from the Simple Threading Wizard (v1.17 I think) after I set the test=true flag. That was what initially confused me and my poor lathe was valiantly trying to do what it said. I suggest this is simply a separate issue that presumably needs addressing as well.
- Use actual spindle speed checked - Hood and others have validated my xml
- Alex's comments about needing a G4P0 explains why I see the G0 feedrate less than the expected, thanks - and I guess that is also why the G1 is also running slowly
- Feedrate <75% of max feedrate is fine, albeit close - but I have seen the problem on finer threads as well when I tried to cut a 0.8mm pitchl
- Unclean index pulse - my thoughts as well, however it looks very clean and sharp on my digital storage scope as viewed at the parallel port connector on the PC
- hardware conflict - also had similar thoughts so I swapped the external PCI card PP over to the onboard one in case it was related to that but no changes occurred
- Mach seems to write to LastErrors all of the time but with less information than if the debug flag is set
I will return to PC and index pulse debug I think - I did test using the Driver Test which seemed ok, is there anything else that I can apply or am I now deep into the workings of my PC and the world of XP?
Regards,
Simon
PS how do you stop bullets taking bold italic fonts??
-
Hard for me to believe its the index pulse, your time of int seems good on the rotation sensing.. BUT, the program has changed a lot since I was in there, Im still using .028 as my version, but it has changes Ive made for myself over time so Im not great anymore at figuring out whats going
on in generalized sense.. My emco hasnt done threading since I wrote the routines..
Art
-
Hi Art,
The code generated from the Simple Threading Wizard ( M1076 configured for G32 output ) always had double G32's as shown in the format below.
Use it whenever I do threading, never questioned the double G32's, but then, never had a problem when using it.
(Decrement = 0.005 pass 1)
G01 Z0
G32 X0.245 Z-0.0014 F0.025
G32 X0.245 Z-0.9969 F0.025
G01 X6.25 Z-1 F0.025
G00 X6.25 Z0
G00 X0.25
RICH
-
Rich:
In theory it can work in a limitded instance, but the second one is redundant, once triggered the motion will simply continue
unabated I think. It will have no real effect, but has dangers if one were to string a bunch together as the triggering wont be as one
would expect. I never understood why the G32 advance was written that way, but then as I said, its been too long, like trying to
second judge a project long put away. :)
Art
-
Hi all,
Simon,
please try the following.
note all your settings in mach on a sheet of paper ( or make a screenshot )
delete the old XML's ( or move it to an other place )
reinstall Mach3 ( be sure to do it as recommended )
reboot PC
important: DO NOT load an old profile ( XML)!
There will be a new fresh Turn Profile
DO NOT load an other screenset as the standart !
type in your settings and test the result.
It looks to me that your XML corrupted the system ( Mach3)
at least it did mine. grrrr :'( :'( ;D
Alex
-
All,
Now that I have deeply investigated my problem and have found a solution, I want to share it with you all in the hope that it may help others in a similar situation as well as as a sort of 'thank you' to everyone who read and contributed to the apparently never ending saga.
Briefly, the problem was that I was unable to cut threads reliably without the lathe deciding at some point to not start a particular pass of the thread. All electronics looked fine and the problem was intermittent. I tried many tests and solutions proposed here as well as my own, none being successful
Finally I resurrected the ancient PC that came with the lathe complete with the original Emco software and installed Mach on top of the French Windows 2000 OS. This proceeded to work perfectly...I have since installed Win XP and reinstalled both Mach3 and the updated screens from Calypso and it continues to work perfectly. Meanwhile the PC that I was using for both the lathe and my mill (not simultaneously!) continues to work perfectly too...
Thus the conclusion that I draw is that that particular PC has some bizarre timing issue that causes problems on time critical items like screwcutting but allows perfect function on the less critical mill. Who knows what, I no longer care!
The moral of the story and the 5 pages of forum space is that if you see an odd problem, try another PC.
Thanks to you all
Simon
-
Glad you have something that works even though we have no definitive answer as to the actual cause in your case.
I can live with your case closed. ;)
RICH
-
Rich,
I really wish I could offer a detailed breakdown of the problem for everyone's benefit but I have lost the enthusiasm for debugging elderly Win XP PCs - if I ever had any!
Hopefully no-one else will suffer similar problems, or if they do, they will consider trying another PC as part of their investigation.
Thanks again to you and the others for your help and efforts.
Simon