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.