Multiple BOB's and parallel ports, and different driver card issues

Greetings....
I recently cleaned up the control system on an ancient Bridgeport BOSS-II mill, including a newer computer (Dell desktop), new parallel port cards, new BOB's, and added a new Gecko (203/ten microstep)) driver card for the new fourth axis, leaving the three existing AhHa controller cards on the XYZ axes since they run fine and support the 10Amps apparently required by the giant stepper motors. The computer has a fresh install of the Stretch AMD64 R13 system, and nothing else.
1. The latency test suggests the max jitter is <15,000 which was set in Stepconfig. This was taken with multiple file transfers happening and downloads off the web.
2. The Axis tests in Stepconfig all run perfectly with the parallel port cards and setup matching the original (Pre upgrades and move)...ie smooth operation of all four axes at maximum speeds and no lost steps. This suggests the control system components are set up correctly and are working.
All of the step/dir/ena lines are on the first port card, along with spindle direction and EStopIn. The spindle brake is on the second port card and also works fine. (limits will be added on the second card once everything else works). All spindle and coolant control functions seem to work perfectly, as does the EStop.
3. Using the AXIS GUI, (set in the .ini file), the operation is very rough with lost steps, and error messages.
4. Using the GMOCCAPY GUI (which I much prefer and have used for the last year), the lost steps increase with error messages.
THE ERRORS usually occur a second or two AFTER commanding movement on an axis, and include:
1. Unexpected realtime Display (dmesg)
2. Linux parallel port 53264 not found [=d010h]
3. Linux parallel port 57360 not found [=e010h]
4. Joint 0 following error (on xyz axes)
5. Joint 3 following error (on a axis)
THE QUESTIONS:
A. Can LinuxCNC actually handle two parallel ports in real time with a GUI? (set to 0xe010, and 0xd010)
B. Can LinuxCNC handle two different types of driver cards in the same system?
C. Why is operation as expected in the stepconfig tests, but not in the GUI's?
D. Is there a possible problem with the new Dell computer, compared to the older Dell tower (with only 1 port used)
E, What can I do to fix this? .HAL and .INI files are attached.

A yes
B yes
C dont know, should not be
D most probably not
E see below
If you are geting all those errors after issuing a motion command, that is a sign there is something very wrong in the viring or motor power supply or grounding/signal isolation. You should really check that first.

kborsum wrote: Greetings....
I recently cleaned up the control system on an ancient Bridgeport BOSS-II mill, including a newer computer (Dell desktop), new parallel port cards, new BOB's, and added a new Gecko (203/ten microstep)) driver card for the new fourth axis, leaving the three existing AhHa controller cards on the XYZ axes since they run fine and support the 10Amps apparently required by the giant stepper motors. The computer has a fresh install of the Stretch AMD64 R13 system, and nothing else.
1. The latency test suggests the max jitter is <15,000 which was set in Stepconfig. This was taken with multiple file transfers happening and downloads off the web.
2. The Axis tests in Stepconfig all run perfectly with the parallel port cards and setup matching the original (Pre upgrades and move)...ie smooth operation of all four axes at maximum speeds and no lost steps. This suggests the control system components are set up correctly and are working.
All of the step/dir/ena lines are on the first port card, along with spindle direction and EStopIn. The spindle brake is on the second port card and also works fine. (limits will be added on the second card once everything else works). All spindle and coolant control functions seem to work perfectly, as does the EStop.
3. Using the AXIS GUI, (set in the .ini file), the operation is very rough with lost steps, and error messages.
4. Using the GMOCCAPY GUI (which I much prefer and have used for the last year), the lost steps increase with error messages.
THE ERRORS usually occur a second or two AFTER commanding movement on an axis, and include:
1. Unexpected realtime Display (dmesg)
2. Linux parallel port 53264 not found [=d010h]
3. Linux parallel port 57360 not found [=e010h]
4. Joint 0 following error (on xyz axes)
5. Joint 3 following error (on a axis)
THE QUESTIONS:
A. Can LinuxCNC actually handle two parallel ports in real time with a GUI? (set to 0xe010, and 0xd010)
B. Can LinuxCNC handle two different types of driver cards in the same system?
C. Why is operation as expected in the stepconfig tests, but not in the GUI's?
D. Is there a possible problem with the new Dell computer, compared to the older Dell tower (with only 1 port used)
E, What can I do to fix this? .HAL and .INI files are attached.

A. yes, if those are in fact the correct addresses. You could also try 0 and 1.
B. yes
C. ? But I've never trusted the tests very much (never worked for me.)
D. Possible, but very unlikely
E. Make sure drive enables are not getting in the way and that the wires for them aren't mixed up with any of the step/dir wires (the Stepconfig tests do not do anything with the enables when testing.)
Your base-thread seems a little long at 100000, and if you are still having real time delay error messages at those speeds, you need to work on that.

It wont fix you latency issues but there are some basic issues with the hal file:
For example you have the steptime and stepspace set to 1 ns!
This only makes sense if you are using hal_parports "reset" mode
but you are not.

Actually, I think it is steplengh 0 for reset, I think 1 without reset, will just turn on the step pulse one base thread cycle then turn it off the next. Stepconfig does this when ever the minimum step length is less than one base-thread cycle, and it isn't using reset. But still it would not hurt to set it to the actual minimum step length.

Interesting....I found that when the stepconfig tests didn't work, there was definitely a problem with the wiring...the enable line in fact. Fixed that issue, and the stepconfig tests worked fine.
I DID have an issue with an inexpensive stepper driver I was trying prior to the Gecko, and discovered its enable line required reverse polarity, so would not work with Linux CNC.

Could you expand on reset? I noticed this in the original old working hal file:
setp parport.0.reset-time 5000
net xstep => parport.0.pin-02-out
setp parport.0.pin-02-out-reset 1
net xdir => parport.0.pin-03-out

Is this something I might try inserting in the newer hal file? What exactly does it do?
Also in that old file, steplen=1, and stepspace=0,

I see "steplen" and "stepspace" for each axis in the latest hal file....and both are set to 1. What would be a suggested value to start with?

OK....I tried duplicating the reset lines in the new hal file. The move commands in AXIS are smoother, but still there are a few step loss's. AND I still see the port not found errors, along with the real time delay...and a following error on the A axis (the Gecko driver)

Also, the Z and A axes both now seem to move a fixed amount and stop...even though "continuous" is specified.

Moving to gmoccapy, the real time error message and the port not found errors pop up immediately in opening the gui. Also, changing "ldrt_parport cfg="0xe010 out 0xd010 out" to cfg = "0 out 1 out" caused an immediate error when loading the GUI.

It sure looks like something is killing the parallel port interface from within the GUI's...any thoughts on this?

Another update:
I remarked out all references to the second parallel port and the XYZA ports run very smoothly at fastest speeds, BUT the Z axis moves INCREMNTALLY rather than continuously.

Restoring the support lines for the second port also restored the lost step problems. The only lines used now on the second port are for the spindle brake and coolant, but I had planned to bring in all the limit switches on this port.

GAAAAH. this is getting frustrating.

Ok that seems like both pci cards are using the same IRQ, so in the BIOS there is a setting pertaining to resource or IRQ asigment that has to be set to manual and edited to have diferent IRQ for those PCI cards.
You should also disable everything that you do not need to have more room to play with, there is a very limited number of IRQ so most stuff has to share them.