Power sequencing of Universal Stepper Controller?
- Einar
- Offline
- Senior Member
Less
More
- Posts: 58
- Thank you received: 2
26 Sep 2013 16:56 #39208
by Einar
Power sequencing of Universal Stepper Controller? was created by Einar
I have been "dry running" the recently received USC board and it works fine now and then.
Which is not what I hoped for. But I think I found out why it does not always work.
My theory is there is no voltage clamping of the parport connector on the board and unlike a printer it needs to be powered up before the PC.
And there seems to be one way of resetting it: Disconnect cable to PC, then power cycle it. Then reconnect to parport.
It seems I need to make a sequencer where my power on switch activate a holding relay. This relay feeds the supply voltage to USC and the coil of another relay that powers the rest of the lathe, including the PC.
Are my observations correct, or just a coincidence?
Which is not what I hoped for. But I think I found out why it does not always work.
My theory is there is no voltage clamping of the parport connector on the board and unlike a printer it needs to be powered up before the PC.
And there seems to be one way of resetting it: Disconnect cable to PC, then power cycle it. Then reconnect to parport.
It seems I need to make a sequencer where my power on switch activate a holding relay. This relay feeds the supply voltage to USC and the coil of another relay that powers the rest of the lathe, including the PC.
Are my observations correct, or just a coincidence?
Please Log in or Create an account to join the conversation.
- jmelson
- Offline
- Moderator
Less
More
- Posts: 817
- Thank you received: 151
27 Sep 2013 03:24 #39242
by jmelson
You can watch the "load fail" LED for a short blink while the FPGA is loading the configuration
from the on-board EPROM. If it doesn't blink, then the config did not load, and the board
will be dead. If the PC parallel port happens to set up with many pins high, it will deliver
"phantom power" to the board. Sometimes you will see the load fail or other LEDs flash
when the board has enough power to start the FPGA configuration process.
To test your hypothesis, get the board in a condition where it is not working, then
disconnect the parallel port cable and remove and reapply power to the board.
then plug in the parallel cable and try LinuxCNC. if this works, then your hypothesis
]is probably right.
There is also the possibility your 12 V power supply has a "bump" in the power-up
curve, and causes the FPGA to fail to configure correctly. This should leave the red
Load Fail LED lit.
You can also try the diagnostics program at pico-systems.com/codes/univstepdiags.tgz
One other note: You **MUST** use an IEEE-1284 cable, and it should have
somethink like "IEEE-1284 compliant" written right on the cable jacket.
Ordinary 25-pin cables do not have the twisted pairs internally to prevent
control signal crosstalk. If you try such a cable, the diagnostics will show MANY
communication errors between the PC and the board.
Jon
Replied by jmelson on topic Power sequencing of Universal Stepper Controller?
Generally, the board should work fine either when powered on before the computer, or after.I have been "dry running" the recently received USC board and it works fine now and then.
Which is not what I hoped for. But I think I found out why it does not always work.
My theory is there is no voltage clamping of the parport connector on the board and unlike a printer it needs to be powered up before the PC.
And there seems to be one way of resetting it: Disconnect cable to PC, then power cycle it. Then reconnect to parport.
It seems I need to make a sequencer where my power on switch activate a holding relay. This relay feeds the supply voltage to USC and the coil of another relay that powers the rest of the lathe, including the PC.
Are my observations correct, or just a coincidence?
You can watch the "load fail" LED for a short blink while the FPGA is loading the configuration
from the on-board EPROM. If it doesn't blink, then the config did not load, and the board
will be dead. If the PC parallel port happens to set up with many pins high, it will deliver
"phantom power" to the board. Sometimes you will see the load fail or other LEDs flash
when the board has enough power to start the FPGA configuration process.
To test your hypothesis, get the board in a condition where it is not working, then
disconnect the parallel port cable and remove and reapply power to the board.
then plug in the parallel cable and try LinuxCNC. if this works, then your hypothesis
]is probably right.
There is also the possibility your 12 V power supply has a "bump" in the power-up
curve, and causes the FPGA to fail to configure correctly. This should leave the red
Load Fail LED lit.
You can also try the diagnostics program at pico-systems.com/codes/univstepdiags.tgz
One other note: You **MUST** use an IEEE-1284 cable, and it should have
somethink like "IEEE-1284 compliant" written right on the cable jacket.
Ordinary 25-pin cables do not have the twisted pairs internally to prevent
control signal crosstalk. If you try such a cable, the diagnostics will show MANY
communication errors between the PC and the board.
Jon
Please Log in or Create an account to join the conversation.
- Einar
- Offline
- Senior Member
Less
More
- Posts: 58
- Thank you received: 2
27 Sep 2013 05:25 #39247
by Einar
Replied by Einar on topic Power sequencing of Universal Stepper Controller?
Your procedure of disconnecting the cable, then power cycling is how I arrived at my hypothesis.
And the testing was done with your test program downloaded from your site. In the case of failure it would not find any boards when running with the "bus" argument. CCable off, power cycle, reconnect the cable, then it would find the board and run commtest and continous IO for as long as I cared checking it. I suppose that means the cable is OK.
Making a power cycling like I wrote will probably be fairly easy. There is a lot of free space in the cabinet after I took out the original control board.
It seems that if (manually) powering up the USC, then turning on the PC it will work every time. At least for the attempts I made. I made a short test just now and when powering on the PC there was a short blink in the red LED, but the Estop LED not light up until I also powered up the USC.
Next up will be to make a configuration for lathe with spindle sensors. I'll try to figure it out from the documentation before asking. But it's good to see that responses comes very quickly when I ask. And I'm sure I will again.
A suggestion to those running this forum is to split the "driver boards" section into subsections covering the different makes. It would be easier to find previous questions and not asking the same questions over again. Which does impose some wear and tear on those spending valuable time to write answers.
And the testing was done with your test program downloaded from your site. In the case of failure it would not find any boards when running with the "bus" argument. CCable off, power cycle, reconnect the cable, then it would find the board and run commtest and continous IO for as long as I cared checking it. I suppose that means the cable is OK.
Making a power cycling like I wrote will probably be fairly easy. There is a lot of free space in the cabinet after I took out the original control board.
It seems that if (manually) powering up the USC, then turning on the PC it will work every time. At least for the attempts I made. I made a short test just now and when powering on the PC there was a short blink in the red LED, but the Estop LED not light up until I also powered up the USC.
Next up will be to make a configuration for lathe with spindle sensors. I'll try to figure it out from the documentation before asking. But it's good to see that responses comes very quickly when I ask. And I'm sure I will again.
A suggestion to those running this forum is to split the "driver boards" section into subsections covering the different makes. It would be easier to find previous questions and not asking the same questions over again. Which does impose some wear and tear on those spending valuable time to write answers.
Please Log in or Create an account to join the conversation.
Moderators: PCW, jmelson
Time to create page: 0.054 seconds