Pico Universal Stepper Voltage setup, configuration, or operation

The high level question is: How can the linuxcnc, pci board, cable, and Pico board be verified for proper operation.
univstepdiags is producing inconsistent results, end of post.
Here is the lspci -vv output:
01:00.0 Communication controller: MosChip Semiconductor Technology Ltd. PCI 9835 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic PCI 9835 Multi-I/O Controller
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 21
Region 0: I/O ports at d050
Region 1: I/O ports at d040
Region 2: I/O ports at d030
Region 3: I/O ports at d020
Region 4: I/O ports at d010
Region 5: I/O ports at d000
Kernel modules: parport_serial

Below is the output of demsg. The port 0xdo30 shows [PCSPP,TRISTATE,EPP] status, is this the correct mode?
dmesg |grep parp
[ 9.684287] parport0: PC-style at 0x378 (0x778)
[ 9.819904] parport0: irq 5 detected
[ 9.984023] parport1: PC-style at 0xd030, irq 21 [PCSPP,TRISTATE,EPP]
[ 10.091425] parport_serial 0000:01:00.0: 0000:01:00.0: unknown NetMos/Mostech device

root@bridgeport-cnc:/home/dan/Downloads# ./univstepdiags 0xd030 bus
io addr = d030
parport addr 0xd030
Bus Map
Board Addr Type Ver.
0 Univ. Stepper 5
2 No Board ff
3 No Board ff
4 Univ. Stepper f
6 Unknown 6f
7 Unknown 7f
8 Unknown 8f
9 Unknown 9f
a Unknown af
b Unknown bf
c Unknown cf
d Unknown df
e Unknown ef
f No Board ff
root@bridgeport-cnc:/home/dan/Downloads# ./univstepdiags 0xd030 bus
io addr = d030
parport addr 0xd030
Bus Map
Board Addr Type Ver.
0 Univ. Stepper 5
2 DAC-16 f
3 DIO f
4 Univ. Stepper f
6 Unknown 6f
7 Unknown 7f
8 Unknown 8f
9 Unknown 9f
a Unknown af
b Unknown bf
c Unknown cf
d Unknown df
e Unknown ef
f No Board ff

dansawyer wrote:

The high level question is: How can the linuxcnc, pci board, cable, and Pico board be verified for proper operation.

parport addr 0xd030
Bus Map
Board Addr Type Ver.
0 Univ. Stepper 5

This is the correct response, it IDs a Universal Stepper at address zero.

parport addr 0xd030
Bus Map
Board Addr Type Ver.
0 Univ. Stepper 5
2 DAC-16 f
3 DIO f
4 Univ. Stepper f

Why is this report different? Are you using a cable labeled for IEEE-1284 compliance? This info may actually be OK, as a rev. F board is considered invalid. (The board ID register is at address XF, where X is the "slot" number. So, it tries 0F, 1F, 2F, etc. to see if a board responds. X0 and XF are considered invalid. So, all those Unknown XF lines are where the capacitance of the cable held the register address for a few us while the read was performed.)

The real torture test is to replace bus with commtest in your command line. This test writes random data to the position counters and then reads it back and compares. Any differences are reported, with a running total of errors.

If you get no errors in 100,000 test cycles, you can consider the communication to be rock solid. That only takes 30 seconds or so.

Jon

Thank you. I have upgraded the cable to a IEE-1284 cable.

The test below is showing over 68,000 errors per 276,000 tests. The good news is it is partially working.

Do you have any pointers on where the best placie to look next, cpu board, pci card, cable, or USC board?

test cycle 275884, axis 0 was / should be
a0 15 a5 / 8d 9f b4
test cycle 275884, axis 1 was / should be
a0 15 a5 / 8d 9f b4
test cycle 275884, axis 2 was / should be
a0 15 a5 / 8d 9f b4
test cycle 275884, axis 3 was / should be
a0 15 a5 / 8d 9f b4
test cycle 275994, axis 0 was / should be
a8 59 49 / 99 fc b
test cycle 275994, axis 1 was / should be
a8 59 49 / 99 fc b
test cycle 275994, axis 2 was / should be
a8 59 49 / 99 fc b
test cycle 275994, axis 3 was / should be
a8 59 49 / 99 fc b
276000 test cycles, 66866 errors
test cycle 276055, axis 0 was / should be
17 18 aa / 87 ab 4c
test cycle 276055, axis 1 was / should be
17 18 aa / 87 ab 4c
test cycle 276055, axis 2 was / should be
17 18 aa / 87 ab 4c
test cycle 276055, axis 3 was / should be
17 18 aa / 87 ab 4c

dansawyer wrote:

Thank you. I have upgraded the cable to a IEE-1284 cable.

The test below is showing over 68,000 errors per 276,000 tests. The good news is it is partially working.

Do you have any pointers on where the best placie to look next, cpu board, pci card, cable, or USC board?

test cycle 275884, axis 0 was / should be
a0 15 a5 / 8d 9f b4
test cycle 275884, axis 1 was / should be
a0 15 a5 / 8d 9f b4
test cycle 275884, axis 2 was / should be
a0 15 a5 / 8d 9f b4
test cycle 275884, axis 3 was / should be
a0 15 a5 / 8d 9f b4

Ugh, that's not a good report. It looks like a handshaking problem, not specifically a data reliability problem,
as the read back data is the same on all 4 axes (a0 15 a5).

Ah, you have a NetMos 9835 chip, that needs an option turned on in your ppmc driver.
In the configs file univstep_load.hal, there will be a line like :
loadrt hal_ppmc port_addr="0xnnnn"
change it to read :
loadrt hal_ppmc port_addr="0xnnnn" epp_dir=1

This changes the way the driver directs the port to switch from read to write and vice versa.
I think this will fix your issue. You do need to run a LinuxCNC version of 2.7.9 or newer for this option to be available.

OH, the above fix is needed for LinuxCNC, but won't help the diagnostic program. In fact, the diagnostic already uses the
same method as the epp_dir=1 causes LinuxCNC to use. So, this might not be the issue.

You might also check the 12 V power supply to the USC board for regulation and ripple. How long is the IEEE-1284 cable? Is the power supply for the UPC grounded to a different power source than the computer? I'm sort of picking at straws here.

Jon

Thank you.
I am using univstepdiags 0xd030 commtest.
The only univstep_laod.hal file is in:
/usr/share/doc/linuxcnc/examples/sample-configs/by_interface/pico/USC_encod/univstep_load.hal
Will univstepdiags find it there? Or do I need to move it somewhere?
I am using a 64 bit system. Below is a copy of that file, I tried to change the line that was closest to the one referenced. (the syntax was not exact so that is suspect.)

cat univstep_load.hal
# sample file pulls all load commands into a single file
# when emc2 starts it loads iocontrol

# kinematics
loadrt [KINS]KINEMATICS
# motion controller, get name and thread periods from ini file
loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[KINS]JOINTS

# next load the PID module, for four PID loops
loadrt pid num_chan=4

# install driver
#if the stepper controller is not connected to the standard parallel port
# at address 0x378, add port_addr="0x1234" to the following line after a space
# on LinuxCNC versions 2.7.9 and above, a parameter allows you to change the
# way the EPP port is controlled. For PCIe cards using the NetMos 990x
# chips, append epp_dir=1 to the end of the following line

# loadrt hal_ppmc

loadrt hal_ppmc port_addr="0x6030" epp_dir=1

# make some signals for the scope for tuning.
loadrt ddt count=4
# add components for E-stop logic
loadrt estop_latch count=1
loadrt and2 count=1

# set up the realtime thread
# read inputs first
addf ppmc.0.read servo-thread
# then run the motion controller
addf motion-command-handler servo-thread
addf and2.0 servo-thread
addf estop-latch.0 servo-thread
addf motion-controller servo-thread
# then the PID loops
addf pid.0.do-pid-calcs servo-thread
addf pid.1.do-pid-calcs servo-thread
addf pid.2.do-pid-calcs servo-thread
addf pid.3.do-pid-calcs servo-thread
# write outputs last
addf ppmc.0.write servo-thread

I jumped too soon.
The cable is 10 feet long, The supply is separate. I will use one of the 12 leads from the ps.
Sorry for jumping too soon. The end of the post makes sense. I am ordering a new, shorter cable.
Thanks for the pointers. I will follow those.

dansawyer wrote:

Thank you.
I am using univstepdiags 0xd030 commtest.
The only univstep_laod.hal file is in:
/usr/share/doc/linuxcnc/examples/sample-configs/by_interface/pico/USC_encod/univstep_load.hal
Will univstepdiags find it there? Or do I need to move it somewhere?

You misunderstand. Univstepdiags does not use any part of LinuxCNC or its drivers. It uses it's own internal driver
to access the parallel port and the USC board. This makes things a lot easier to test, and the diagnostic program only tests one function at a time.

When you first select a configs file set from the config picker dialog when you start LinuxCNC, it asks if you want to make a copy of the configs. You should answer yes. This copy will go under your used directory, usually in subdirectory
linuxcnc/configs

You will then have privileges to edit it there. univstep_load.hal will pull in all the hal components needed to run the sample
configuration.

I am using a 64 bit system. Below is a copy of that file, I tried to change the line that was closest to the one referenced. (the syntax was not exact so that is suspect.)

Again, this has nothing to do with the diagnostic program, but will have to be done to run LinuxCNC.

Jon

dansawyer wrote:

The high level question is: How can the linuxcnc, pci board, cable, and Pico board be verified for proper operation.
univstepdiags is producing inconsistent results, end of post.
Here is the lspci -vv output:
01:00.0 Communication controller: MosChip Semiconductor Technology Ltd. PCI 9835 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic PCI 9835 Multi-I/O Controller
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 21
Region 0: I/O ports at d050
Region 1: I/O ports at d040
Region 2: I/O ports at d030
Region 3: I/O ports at d020
Region 4: I/O ports at d010
Region 5: I/O ports at d000
Kernel modules: parport_serial

Below is the output of demsg. The port 0xdo30 shows [PCSPP,TRISTATE,EPP] status, is this the correct mode?
dmesg |grep parp
[ 9.684287] parport0: PC-style at 0x378 (0x778)
[ 9.819904] parport0: irq 5 detected
[ 9.984023] parport1: PC-style at 0xd030, irq 21 [PCSPP,TRISTATE,EPP]
[ 10.091425] parport_serial 0000:01:00.0: 0000:01:00.0: unknown NetMos/Mostech device

root@bridgeport-cnc:/home/dan/Downloads# ./univstepdiags 0xd030 bus
io addr = d030
parport addr 0xd030
Bus Map
Board
Addr Type Ver.
The following line,is OK Univ. Stepper 5
4 Univ. Stepper f
6 Unknown 6f
7 Unknown 7f
8 Unknown 8f
9 Unknown 9f
a Unknown af
b Unknown bf
c Unknown cf
d Unknown df
e Unknown ef
f No Board ff
root@bridgeport-cnc:/home/dan/Downloads# ./univstepdiags 0xd030 bus
io addr = d030
parport addr 0xd030
Bus Map
Board***the following line isOK

0 Univ. Stepper 5
2 DAC-16 f
3 DIO f
4 Univ. Stepper f
6 Unknown 6f
7 Unknown 7f
8 Unknown 8f
9 Unknown 9f
a Unknown af
b Unknown bf
c Unknown cf

d Unknown df
e Unknown ef
f No Board ff