Re: [Emc-developers] 7i76 vs spinout signal
On Monday 04 February 2019 12:09:05 Peter C. Wallace wrote: > On Mon, 4 Feb 2019, Gene Heskett wrote: > > Date: Mon, 4 Feb 2019 05:13:08 -0500 > > From: Gene Heskett > > Reply-To: EMC developers > > To: emc-developers@lists.sourceforge.net > > Subject: Re: [Emc-developers] 7i76 vs spinout signal > > > > On Sunday 03 February 2019 20:03:28 Peter C. Wallace wrote: > >> On Sun, 3 Feb 2019, Gene Heskett wrote: > >>> Date: Sun, 3 Feb 2019 19:56:53 -0500 > >>> From: Gene Heskett > >>> Reply-To: EMC developers > >>> To: emc-developers@lists.sourceforge.net > >>> Subject: Re: [Emc-developers] 7i76 vs spinout signal > >>> > >>> On Sunday 03 February 2019 09:30:46 Peter C. Wallace wrote: > On Sun, 3 Feb 2019, Gene Heskett wrote: > >>> > >>> getting TLDR, clipped most of whats been solved > >>> > The 7I76 spindle ENA and DIR outputs are independent of the > analog value of spinout, (though the analog out is forced to 0 if > spinena is false) is it possible you have a wiring error? > >>> > >>> This is solved and it looks like I can excise that other stuff > >>> from the hal file. > >>> > >>> Now, re a lack of response at the actual outputs 15 and 14. > >>> > >>> I did a setp to set invert true, made them come on when they > >>> should have been off so I setp them to false, and now they are > >>> working as desired. > >> > >> I dont think thats the case, I suspect you misdiagnosed the initial > >> test > > > > While thats always a possibility, but its a test reading I did > > multiple times for both conditions, and until I added the > > setp output-invert true, > > which made it backwards, so I setp'd it false and it works as > > expected. > > If thats really case, I think you may have a thread order or other > error in your hal file. > > Is certainly not a known problem with 7I76 outputs, and I just > verified here that they work as expected. > > > ATM its the middle of the night and I'm trying to see if I have all > > 4 stepgens ready to hook up later today, and I find I cannot see the > > actual steps with a halscope any place. So I'll have to scope probe > > the 7i76 stepgen pulse outputs. Is this correct? Or is there a way > > to see them on a halscope pin when there is no base thread? I can't > > find an output that shows them, Probably too short for halscope > > running on srevo-thread to see. I can see the dir changes at the > > corresponding gpio.in, so I assume they are working. I'll try to get > > that all hooked up today, leaving the home switches and encoder to > > sort tomorrow. And that should get that mill 100% usable again. > > Leaving me plotting how to make a tool changer for it. And > > searching for an endoscope camera that actually works. > > > > On another front, I have the alignment kit working well on the 6040 > > already. Theoretically, just copying that code to this machine > > should handle that. easy-peasy on the 6040 as the workpiece is > > usually mounted on a spoil board and therefore insulated, so it > > could be made to use a G38.2 to detect the angular error. Aligning > > the machine to the workpiece rather than the other way around. > > You can allways temporarily set the step mode to quadrature > you can always get about 50% state read on a undersample > (the likely hood of catchinh a 1 usec pulse at 1 KHz is only 1 in a > 1000) > I took ohms readings on it at the card input point, figured the shield of the existing was ground, and I faintly recalled the power lead to the omron was the 5 volt supply and it would be a lower ohmage. That left 3 unidentified leads, two of which had nearly identical ohms to ground while the third was obviously different as it comes from the old optical index on the spindle, not from the omron on the motor by way of a couple rs455 receivers in a little box in the middle of the encoder cable. My cable has two shielded pair, a blk-wht and a blk/red. So I hooked the shields to ground, the red wire to 5 volts, the blk wires to enca+ and encb+ and the wht to idex+. I even got lucky and had the black wires correct, the raw count moves in the right direction when the spindle is turned by hand. So that should be solved, then I read the comment about wiring limits etc on page 14, and assumed it also applies to home switches. Which doesn't match my current setup, so I'm in the early stages of putting in new switches and wireing it up according to that comment on page 14. I'd had some trouble getting a decent printout of that 7i76.pdf though, it (okular) insists the printer render it in landscape, which clips off the top and bottom of the pages, then I found that it wasn't composed for letter sized paper, but for A4. So I shrunk it to 95% in evince and now I have everything on paper that I see on-screen. And I have a bunch of notes on the copy I'm working from to copy to this printout. And while okular seems stuck in landscape mode, evince printed it portrait like it was told. Happy camper. The missus was
Re: [Emc-developers] 7i76 vs spinout signal
On Mon, 4 Feb 2019, Gene Heskett wrote:
Date: Mon, 4 Feb 2019 05:13:08 -0500
From: Gene Heskett
Reply-To: EMC developers
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] 7i76 vs spinout signal
On Sunday 03 February 2019 20:03:28 Peter C. Wallace wrote:
On Sun, 3 Feb 2019, Gene Heskett wrote:
Date: Sun, 3 Feb 2019 19:56:53 -0500
From: Gene Heskett
Reply-To: EMC developers
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] 7i76 vs spinout signal
On Sunday 03 February 2019 09:30:46 Peter C. Wallace wrote:
On Sun, 3 Feb 2019, Gene Heskett wrote:
getting TLDR, clipped most of whats been solved
The 7I76 spindle ENA and DIR outputs are independent of the analog
value of spinout, (though the analog out is forced to 0 if spinena
is false) is it possible you have a wiring error?
This is solved and it looks like I can excise that other stuff from
the hal file.
Now, re a lack of response at the actual outputs 15 and 14.
I did a setp to set invert true, made them come on when they should
have been off so I setp them to false, and now they are working as
desired.
I dont think thats the case, I suspect you misdiagnosed the initial
test
While thats always a possibility, but its a test reading I did multiple
times for both conditions, and until I added the
setp output-invert true,
which made it backwards, so I setp'd it false and it works as expected.
If thats really case, I think you may have a thread order or other error in
your hal file.
Is certainly not a known problem with 7I76 outputs, and I just verified here
that they work as expected.
ATM its the middle of the night and I'm trying to see if I have all 4
stepgens ready to hook up later today, and I find I cannot see the
actual steps with a halscope any place. So I'll have to scope probe the
7i76 stepgen pulse outputs. Is this correct? Or is there a way to see
them on a halscope pin when there is no base thread? I can't find an
output that shows them, Probably too short for halscope running on
srevo-thread to see. I can see the dir changes at the corresponding
gpio.in, so I assume they are working. I'll try to get that all hooked
up today, leaving the home switches and encoder to sort tomorrow. And
that should get that mill 100% usable again. Leaving me plotting how to
make a tool changer for it. And searching for an endoscope camera that
actually works.
On another front, I have the alignment kit working well on the 6040
already. Theoretically, just copying that code to this machine should
handle that. easy-peasy on the 6040 as the workpiece is usually mounted
on a spoil board and therefore insulated, so it could be made to use a
G38.2 to detect the angular error. Aligning the machine to the workpiece
rather than the other way around.
You can allways temporarily set the step mode to quadrature
you can always get about 50% state read on a undersample
(the likely hood of catchinh a 1 usec pulse at 1 KHz is only 1 in a 1000)
Thanks Peter.
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 7i76 vs spinout signal
On Sunday 03 February 2019 20:03:28 Peter C. Wallace wrote:
> On Sun, 3 Feb 2019, Gene Heskett wrote:
> > Date: Sun, 3 Feb 2019 19:56:53 -0500
> > From: Gene Heskett
> > Reply-To: EMC developers
> > To: emc-developers@lists.sourceforge.net
> > Subject: Re: [Emc-developers] 7i76 vs spinout signal
> >
> > On Sunday 03 February 2019 09:30:46 Peter C. Wallace wrote:
> >> On Sun, 3 Feb 2019, Gene Heskett wrote:
> >
> > getting TLDR, clipped most of whats been solved
> >
> >> The 7I76 spindle ENA and DIR outputs are independent of the analog
> >> value of spinout, (though the analog out is forced to 0 if spinena
> >> is false) is it possible you have a wiring error?
> >
> > This is solved and it looks like I can excise that other stuff from
> > the hal file.
> >
> > Now, re a lack of response at the actual outputs 15 and 14.
> >
> > I did a setp to set invert true, made them come on when they should
> > have been off so I setp them to false, and now they are working as
> > desired.
>
> I dont think thats the case, I suspect you misdiagnosed the initial
> test
>
While thats always a possibility, but its a test reading I did multiple
times for both conditions, and until I added the
setp output-invert true,
which made it backwards, so I setp'd it false and it works as expected.
ATM its the middle of the night and I'm trying to see if I have all 4
stepgens ready to hook up later today, and I find I cannot see the
actual steps with a halscope any place. So I'll have to scope probe the
7i76 stepgen pulse outputs. Is this correct? Or is there a way to see
them on a halscope pin when there is no base thread? I can't find an
output that shows them, Probably too short for halscope running on
srevo-thread to see. I can see the dir changes at the corresponding
gpio.in, so I assume they are working. I'll try to get that all hooked
up today, leaving the home switches and encoder to sort tomorrow. And
that should get that mill 100% usable again. Leaving me plotting how to
make a tool changer for it. And searching for an endoscope camera that
actually works.
On another front, I have the alignment kit working well on the 6040
already. Theoretically, just copying that code to this machine should
handle that. easy-peasy on the 6040 as the workpiece is usually mounted
on a spoil board and therefore insulated, so it could be made to use a
G38.2 to detect the angular error. Aligning the machine to the workpiece
rather than the other way around.
Thanks Peter.
>
> Peter Wallace
> Mesa Electronics
>
> (\__/)
> (='.'=) This is Bunny. Copy and paste bunny into your
> (")_(") signature to help him gain world domination.
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
