Back
[02:14:13] <Deejay> moin
[02:14:29] <Jymmm> hi Deejay
[02:14:32] <Jymmm> alex_joni: ping
[02:14:37] <Deejay> hi Jymmm :)
[06:04:21] <eg1> Hi all, Question: Anyone tried to pwm-control a rectified mains with a universal motor for a spindle? pwm through linuxcnc
[06:07:49] <archivist> there are some drives that do that. the one in my lathe is similar but has a pot, I modded a similar one for a friend in a Boxford mill with a small filter off the pwm output
[06:08:36] <archivist> best via an opto of course
[06:10:33] <eg1> thanks, arch. I was looking for a schematics example. It should be doable with the linuxcnc pwm and pid controller modules, right? Yes I'd use optos
[06:11:54] <archivist> I did not use the pid
[06:12:36] <eg1> Well whilst at it I'd go for closed loop rpm control, I thought
[06:17:35] <archivist> I know my lathe needs better control, speed varies when set to a speed
[06:20:02] <eg1> thought as much
[06:20:54] <eg1> But if I wanted to build the electronicy maself, there are caveats:
http://forum.allaboutcircuits.com/showthread.php?s=eec6fe941309edf4be7cb6fcfea72648&t=60972
[06:23:07] <archivist> there are some triac/thyristor motor speed controls on fleabay cheap
[06:23:59] <archivist> also one needs to make sure the devices current share properly
[06:25:49] <archivist> make sure you catch spikes too
[06:26:02] <eg1> yes something like this but I need the 250v version
http://www.ebay.com/itm/PWM-Speed-Controller-For-300W-CNC-Spindle-Motor-Kits-Support-AC-And-DC-Input-/221342720930?pt=LH_DefaultDomain_0&hash=item33890de3a2
[06:28:13] <eg1> I have a triac/thyristor pot regulator already - with mains filter from a PC power supply :-) - but I want pwm rpm control throu the pinuxcnc realtime
[06:43:45] <eg1> alright thanks arch
[07:33:20] <emcPT> Hello to all.
[07:33:34] <emcPT> In a system with analog control
[07:34:10] <emcPT> and in witch, the drives during the inicialization process
[07:34:14] <emcPT> move the axis
[07:34:34] <emcPT> there is any way to tell to linuxcnc to discard the initialization movement?
[07:35:42] <archivist> are you wanting touch off after homing
[07:35:48] <emcPT> The issue is that, soon after the drives are initializated, linuxcnc seaks the original point, resulting in a fast loud movement in all axes, that in my case are 3 at the same time
[07:36:19] <archivist> you can program the homing sequence
[07:36:39] <emcPT> @archivist: Not a homing issue.
[07:37:03] <emcPT> I explain better: I have analog servos, controlled in closed loop with a 7i77
[07:37:16] <emcPT> When the machine is powered on
[07:37:38] <emcPT> the drives initialize, by its internal sequence, resulting in movement
[07:37:53] <emcPT> that was not comanded by linuxcnc
[07:38:18] <emcPT> It is the drive that needs to calibrate itself (I think to know where the motor poles are)
[07:38:54] <archivist> if you sequence the enables it will be nicer
[07:39:16] <emcPT> Ok
[07:39:47] <archivist> the homing after is removing that offset
[07:40:23] <emcPT> the issue is not that. I explain again.
[07:40:32] <emcPT> linuxcnc starts
[07:40:39] <archivist> I know
[07:41:18] <emcPT> then estop is removed
[07:41:25] <emcPT> then poweron
[07:41:28] <archivist> homing sets the macing reference removing any movements that were done before control was gained
[07:41:48] <emcPT> ... oh
[07:41:59] <emcPT> that is probably that I need
[07:42:39] <emcPT> currently I have a homing sequence, that is working very good.
[07:42:54] <archivist> should be ok then
[07:43:13] <emcPT> But I only ask for home AFTER the drives are initialized
[07:43:21] <emcPT> this is, after the problem occurs
[07:43:39] <emcPT> that is a "jump" right after drives are initialized.
[07:44:22] <R2E4> More work on new Panel.
http://irmtl.com/LinuxCNC/VM40/vm40panel.JPG
[07:44:39] <emcPT> I must find a way, that during initialization, linuxcnc does not look to the commanded position
[07:45:07] <emcPT> because the feedback position is moving due to the drive initialization
[07:45:31] <archivist> yes that means a delay before you enable the loop I think
[07:45:37] <Jymmm> R2E4: Uh, where does the gallon of wood glue go in the new panel?
[07:45:49] <Jymmm> err, half galllon =)
[07:46:26] <emcPT> no. the delay will not help, as the feedback postion will not be the same as the comanded position
[07:46:51] <emcPT> and the delay will not help, in this situation
[07:46:55] <emcPT> i think
[07:46:56] <archivist> emcPT, so wait for the drives to become true/ready before linuxcnc takes control
[07:47:24] <emcPT> and that is possible how? Sorry if it is a basic question
[07:47:34] <emcPT> There is any pin for the purpose?
[07:47:52] <emcPT> But yes that would be ok
[07:47:56] <emcPT> for this issue
[07:48:14] <archivist> probably, not looked for it as I dont have servos yet :(
[07:49:16] <archivist> emcPT,
http://www.linuxcnc.org/index.php/english/forum/21-axis/27153-disable-home-buttons-until-servo-ready-signal
[07:49:31] <R2E4> That holds the panel in the Control Cabinet...
[07:51:14] <Jymmm> R2E4: Gawd, I hope not! lol
[07:51:49] <Jymmm> R2E4: Looks nice so far =)
[07:52:31] <Jymmm> R2E4: Is that a dimmable outlet I see?
[07:52:50] <emcPT> @archivist: Thank you. I will try to implement the situation: Only make possible to power on the machine IF the servos are ready. This looks a possible solution!
[07:54:51] <Jymmm> EMC could be placed in STANDBY till the servos were ready.
[07:56:03] <emcPT> STANDBY is some sort of a pin or a state that I can control?
[07:56:40] <Jymmm> I believe so, but I'm not sure of STANDBY would have the motor drives enabled or not.
[07:56:59] <Jymmm> even if in a holding pattern (so to speak)
[08:00:36] <Jymmm> emcPT: Do your motors have a "READY" signal of some kind?
[08:01:17] <emcPT> Yes, I know when the drives are ready to work, like enabled
[08:01:44] <Jymmm> emcPT: It has a seperate wire for this?
[08:01:53] <emcPT> Yes
[08:02:10] <Jymmm> emcPT: What voltage/signalling does it use?
[08:02:13] <emcPT> 5
[08:02:40] <emcPT> If your thinking is to connect to the estop
[08:02:45] <Jymmm> +5VDC = READY, 0VDC NOT_READY ???
[08:02:51] <emcPT> Yes
[08:02:59] <emcPT> but I am able to invert it also
[08:03:37] <Jymmm> sure, hang on checking something...
[08:04:58] <Jymmm> You could hook that line to charge pump as more of a hardwired solution instead of in software
[08:07:10] <Jymmm> Well, I feel a REAL estop (safety relays) should stop everything to prevent any movement/hazard at the push of the BIG RED BUTTON. The pseudo-e-stop is up to you.
[08:07:10] <emcPT> I think that the 7i77 does not use a charge pump
[08:07:59] <emcPT> I will see the posibilitys
[08:08:04] <emcPT> Thank you.
[08:09:22] <Jymmm> emcPT: You have a 5i25 too?
[08:09:34] <emcPT> yes
[08:09:35] <R2E4> Power-on halui.machine.on <= hm2_5125.0.7i77.0.0.input-00
[08:09:49] <R2E4> does that work to turn on the machine?
[08:09:56] <emcPT> will try
[08:11:40] <R2E4> oops, forgot the net
[08:12:15] <R2E4> net power-on halui.machine.on <= hm2_5i25.0.7i77.0.0.output-03
[08:13:24] <Jymmm> emcPT: There is mention of charge pump in the 5i25 manual for use with G540, I'msure that could be adopted for use with the 7i77 instead.
[08:14:38] <R2E4> nope doesnt work
[08:17:40] <emcPT> Jymmm: The 5i25 does not have a charge pump (i think). It seams that only a watchdog is present
[08:17:54] <archivist> not a charge pump situation methinks anyway
[08:19:37] <Jymmm> I see a watchdog timer, pcw_home might know better. I was just thinking the charge pump might be a simple solution is all.
[08:20:41] <emcPT> Ok thank you all. I must now think on possible solutions.
[08:22:40] <jdh> do the startup part in ladder so you can power up the drives but leave linuxcnc out of it until initialization is complete?
[08:24:53] <Jymmm> Disable PWR_ON till SERVO_READY signal is received?
[08:25:14] <emcPT> One particular problem with the analog set up is that the analog output from the 7i77 is not exacly zero, so it means that the motor will move a bit when linuxcnc is not in control
[08:25:59] <emcPT> so, if the drives are on, but power on is off, the drives move continuouslly
[08:26:10] <emcPT> slowlly, but they move.
[08:31:26] <jthornton> can you zero the encoder count before enabling the drives?
[08:32:32] <Jymmm> jthornton: Where is the list of pins? It's not in the manual
[08:36:41] <jthornton> while the config is running in a terminal do halcmd show pin > pins.txt
[08:36:56] <jthornton> the pins vary depending on the mode selected
[08:37:30] <emcPT> I can. But that is also not a solution. Imagine that the homing is done, if I power off then I would be forced to home again as the machine will loose the sense of the world
[08:38:19] <skunkworks> emcPT, you should not have the drives enabled until linuxcnc is in control...
[08:38:23] <jthornton> power off what?
[08:39:13] <emcPT> skunkwork: 1) Linuxcnc is in control
[08:39:17] <archivist> skunkworks, his drives self seek before linuxcnc should attempt to control
[08:39:28] <emcPT> correct
[08:39:31] <skunkworks> oh..
[08:39:38] <archivist> he needs to wait for drives ready
[08:39:42] <skunkworks> sure
[08:39:54] <emcPT> like "do not listen to the drives"
[08:40:00] <jthornton> do the drive only self seek when the enable is on?
[08:40:23] <jdh> there should be a zero offset to take care of that.
[08:40:50] <archivist> ac servo finding the phases
[08:41:09] <jthornton> emcPT, when do the drives do the self seek?
[08:42:04] <emcPT> the problem are not offsets. It is the movement that the drives make for their on, like archivist is saying, and as the drives are enabled, linuxcnc, though the analog signal makes the drives go as fast as possible to the initial position (before the drives started to
[08:42:07] <emcPT> initialize)
[08:42:16] <archivist> at power on or at enable ?
[08:42:22] <jthornton> ??
[08:42:33] <emcPT> This results in a big, unprofessional noise as all the axis move.
[08:42:43] <jthornton> yes we know that
[08:42:56] <jthornton> when does the drive do the self seek?
[08:43:25] <emcPT> jthornton: The drives auto seek in the first enable, that is the first time that I press power on (the button next to estop)
[08:44:00] <emcPT> After the drives are enable, I can freely power on/off as the drives do not move anymore for them selfs
[08:44:44] <jthornton> can you have a manual enable before you start LinuxCNC so the drives are on but not enabled when LinuxCNC starts up
[08:45:15] <Jymmm> jthornton: then the drives will "wobble" untill under emc control
[08:45:34] <cradek> if the encoders are hooked to linuxcnc correctly, at machine-on time the command equals the feedback position that it has been reading all along
[08:46:02] <Jymmm> But this doesn't sound any different than waiting to a spindle to get up to speed, or a coolant pump flowing at full capacity, does it?
[08:47:06] <emcPT> cradek: The encoders are correct. The issue is that the machinve moves without emc asks for it, because the drives are self tuning, and not listening to the comanded position from emc
[08:47:32] <emcPT> only after it looks for it, and a large movement is made. After that the machine is perfect.
[08:48:02] <cradek> oh these are ac servos that have to wiggle themselves to get oriented?
[08:48:08] <Jymmm> jthornton: cradek is there a hal STANDBY pin?
[08:49:20] <cradek> (I really dislike that behavior) but you could have them do their wiggle when coming out of estop - see demo-sim-cl for hooking ladder into that coming-out-of-estop loopback
[08:49:46] <cradek> then by the time you do "machine on" they won't be wiggling anymore
[08:50:57] <emcPT> cradek: Correct, but if the drives are initialized and the analog signal is arround zero, but not zero (this is without emc control), they will move slowlly, but continuous.
[08:51:12] <emcPT> so, a larger problem than the movement that I am having now
[08:51:16] <Jymmm> cradek: They will still "wobble" until POWER ON
[08:51:29] <cradek> yes they will creep if enabled but not under pid control
[08:52:00] <cradek> there is no loopback for machine-on, though
[08:52:44] <cradek> in your ladder you could have a timeout: have the machine estop itself again, if the user doesn't turn machine-on in a reasonable time
[08:52:47] <Jymmm> cradek: He has a SERVO_READY signal he can use, just needs some way to place EMC POWERED_ON, butt in STANDBY_ until this signal is enabled.
[08:53:01] <Jymmm> but*
[08:53:01] <cradek> you can set the creep to be minimal (and you should)
[08:53:08] <cradek> Jymmm: I totally understand the problem, thanks
[08:53:30] <Jymmm> cradek: Ok, so is there a STANDBY pin?
[08:53:31] <cradek> there is no loopback for machine-on so there's no place to easily stick that
[08:53:51] <Jymmm> or PAUSE/HALT etc
[08:54:07] <cradek> there IS for coming out of estop (some machines sequence up lots of things then)
[08:55:23] <cradek> you might think you could disable pid until it's done wiggling, but that is a mistake, because when it's done wiggling it will have moved, and you'll get a position jump and servo faults when you reenable it.
[08:55:24] <Jymmm> So MACHINE_ON, they do there self tuning, then ESTOP_DISABLE ?
[08:55:30] <Jymmm> their*
[08:55:31] <cradek> no!
[08:55:45] <cradek> you must do the wiggle before machine-on
[08:55:56] <emcPT> I am understanding
[08:56:21] <emcPT> The timmer could be a solution.
[08:56:43] <cradek> emcPT: compared to the wiggle, I doubt a few seconds of creep would hurt anything, but I do think you should limit it with time
[08:57:00] <Jymmm> Maybe, but random physical movement under no control is a BAD THING imo
[08:57:21] <cradek> yes, I agree a servo system that gives unwanted motion is a bad design. but that's what some of them do.
[08:58:03] <Jymmm> Do the 5i25/7i77 have a charge pump he could hook into somehow?
[08:58:25] <cradek> I don't understand what you mean
[08:58:54] <emcPT> Currently the machine is safe as no movement, exept the initial wiggle (that is small, maybe 2mm max), occurs. The worst is the jump that they do as soon the drive accepts the analog
[08:58:56] <emcPT> signal
[08:59:07] <emcPT> Maybe I will keep it as it is
[08:59:17] <cradek> position jump is really bad
[09:00:02] <cradek> if it doesn't immediately fault on a 2mm jump, you've got your ferrors set way way too high for safety
[09:00:37] <cradek> ferror limit in software and probably also current limit in the amps
[09:01:50] <emcPT> yes they are big ...
[09:01:58] <cradek> that's bad bad bad
[09:02:22] <emcPT> I know, that is why I am asking for help ...
[09:02:41] <Jymmm> It sound like the only solution is to incorporate the SERVO_READY signal into the estop chain to prevent form coming out of estop until SERVO_READY is enabled. Does that sound right?
[09:02:43] <cradek> my advice fixes all of it except the creep, which you can control
[09:03:26] <emcPT> the creep is the movement with the pid disconected, correct?
[09:03:29] <cradek> Jymmm: yes, that's right, there's an estop-reset loopback for that reason
[09:04:03] <cradek> emcPT: yeah, and you can set your offset knobs to minimize it, and also do the estop-reset timeout
[09:04:16] <cradek> I bet it will be very small compared to the 2mm wiggle
[09:04:37] <Jymmm> cradek: Sounds like a shitty but doable solution.
[09:05:15] <cradek> yes, but IMO the shitty is all in the gives-unwanted-motion servo amps
[09:05:23] <emcPT> "offset knobs"? On the 7i77, they do not exist
[09:05:28] <emcPT> I think
[09:05:40] <cradek> surely the amps have offset knobs if they're velocity mode
[09:05:54] <emcPT> no
[09:06:03] <emcPT> that I have sure
[09:06:11] <Jymmm> cradek: well, self-tuning doens't sound like an unreasonable functionality of them.
[09:07:26] <Jymmm> Around here it seems PID is a four letter word =)
[09:07:57] <JT-Shop> could you block the encoder and do the post in ladder?
[09:08:45] <JT-Shop> and as an axis becomes ready disable it
[09:09:39] <Jymmm> How does ec handle when you have to wait for a spindle to get up to speed before proceeding?
[09:09:44] <JT-Shop> and reconnect the encoder count to axis.N.motor-pos-fb
[09:10:09] <R2E4> woohoo! 7i84 on the way
[09:10:11] <cradek> JT-Shop: then you'll get a position jump, which is the whole thing he's trying to eliminate
[09:10:47] <emcPT> cradek: Correct
[09:10:52] <JT-Shop> what was I thinking?
[09:11:03] <Jymmm> JT-Shop: Hamburgers
[09:11:14] <emcPT> It is always hard to see others problems
[09:11:56] <cradek> JT-Shop: heh - above, I wrote "you might think ... but that would be a mistake ..."
[09:12:38] <JT-Shop> there is an encoder reset
[09:13:04] <JT-Shop> so if you do the post then reset the encoder that could work
[09:13:30] <archivist> hold it reset till drives ready
[09:13:55] <emcPT> archivist: motors move ...
[09:14:20] <cradek> I don't know what this encoder reset is
[09:14:25] <emcPT> JT-Shop: Then each time power on is pressed, machine will loose its position and a homing is needed
[09:14:48] <emcPT> Currently I only need to home once per session
[09:14:55] <archivist> are suggesting holding the encoder counter at zero so no command to move it
[09:14:56] <Jymmm> emcPT: what drives are these?
[09:15:08] <emcPT> Granite Devices
[09:15:13] <emcPT> VSD
[09:15:14] <Jymmm> emcPT: PN ?
[09:15:17] <cradek> but that's not even possible is it?
[09:15:28] <emcPT> PN?
[09:15:34] <emcPT> what is it?
[09:15:35] <archivist> part number
[09:15:48] <emcPT> VSD
[09:15:54] <Jymmm> k
[09:15:57] <cradek> with my suggested setup, position is not ever lost, even during the wiggle
[09:16:36] <Jymmm> emcPT: XE or E ?
[09:16:41] <emcPT> E
[09:16:41] <JT-Shop> hm2_5i25.0.encoder.00.reset
[09:16:49] <JT-Shop> resets the encoder count to 0
[09:16:51] <emcPT> it is the same as XE, but for lower amps
[09:17:47] <cradek> JT-Shop: wild. I don't know when you'd ever want to use that...
[09:17:58] <Jymmm> There is a START_HOMING, SERVO_READY, HOMING_STATUS signals
[09:18:08] <Jymmm> http://granitedevices.com/assets/images/prods/vsdeIO.png
[09:18:36] <Jymmm> and a DISABLE TOO
[09:18:46] <cradek> oh hey, you could home upon estop-reset, and when it's done homing, DISABLE the amp again until machine-on
[09:18:53] <emcPT> Start homing is not usable in velocity mode
[09:18:54] <cradek> that is a perfect solution
[09:18:59] <emcPT> Servo ready I am using
[09:19:05] <emcPT> Disable I am using
[09:19:49] <Jymmm> emcPT: they wobble even when using DISABLE ?
[09:20:29] <emcPT> I think no. No movement in disable mode
[09:20:34] <emcPT> Almost sure
[09:20:39] <emcPT> Yes I am sure
[09:21:47] <Jymmm> So, could you wire DISABLE to EMC till MACHINE_ON ?
[09:21:55] <emcPT> Currently I am using the disable line conected to power on off linuxcnc
[09:22:22] <emcPT> But at first enable, the drives will move for initialize
[09:22:23] <Jymmm> emcPT: but it jumps to find position upon MACHINE_ON ?
[09:22:48] <emcPT> After the initialize, yes, the jump occurs. After that I have the perfet machine.
[09:22:49] <cradek> emcPT: did you see what I said? upon estop-reset you could do the wiggle and when it's done, disable the amps again until machine-on
[09:23:43] <emcPT> Sorry I read it before, but did not understood correcly...
[09:23:48] <emcPT> A moment, please
[09:24:07] <emcPT> THAT sounds perfect!
[09:24:27] <cradek> yes there's no reason to leave them enabled
[09:24:47] <Jymmm> Does DISABLE include the intitializing sequence or ignore it?
[09:25:50] <emcPT> As the drives only need to do the initialization thing once (if the power is not disconected), the disable only prevents movements (like ignore the analog input)
[09:26:13] <emcPT> Enable/disable is the same signal, this is, it is enable or disable
[09:26:32] <Jymmm> emcPT: If DISABLE is active, will they still do their initialization thing?
[09:28:18] <emcPT> no, if they did enable once (if they initialized once in the session)
[09:29:19] <emcPT> craked: If fails if the user presses estop-reset then (without wait) the power on
[09:29:27] <emcPT> as normally I do.
[09:31:23] <Jymmm> Is this of any significance???
[09:31:27] <Jymmm> Delaying power-up
[09:31:27] <Jymmm> If necessary, drive motor control start-up can be delayed by driving logic 1 value to user configured disable input while power supplies are switched on. Drive begins motor initialization after disable input value is released to logic 0. Disable input must stay low during whole initialization process (i.e. while blue led not constantly on). If drive gets interrupted by disable signal during initialization process, an initialization fault co
[09:31:27] <Jymmm> ndition will occur. Init fault can be cleared only by power cycling.
[09:34:14] <emcPT> I do not think so
[09:34:24] <Jymmm> Hmmm... Disable drive: If this input has logic value 1, drive will disable motor control and let motor free-wheel.
[09:35:58] <emcPT> In my system the motors do not free wheel as there are no gravitation forces. So having them disable is ok for a stand by mode.
[09:36:19] <Jymmm> Ok, just wanted to mention it at least.
[09:40:39] <Jymmm> emcPT: Well, if you can't get it to work for CNC, you can always use them for frig or LED control, LOL
http://granitedevices.com/wiki/VSD-E_and_VSD-XE
[09:41:26] <Jymmm> emcPT:
http://granitedevices.com/wiki/VSD-E_and_VSD-XE#Other_uses
[09:55:44] <Jymmm> emcPT: Maybe you could ask what they did...
http://www.cnczone.com/forums/granite_devices/139279-homing_hard_stop_problems.html
[10:03:34] <R2E4> How do you add a signal to a contact in classic ladder? Been reading the docs but I cant seem to wrap head around this concept.
[10:04:58] <R2E4> re: I have a run with a N/O contact and a coil. I want to add input for contact and i want halui.machine.on as the coil.
[10:06:16] <R2E4> The docs get you through to adding the rungs, contacts and coils but does nto show how to add signals to them.
[10:06:25] <R2E4> Using the gui
[10:11:43] <JT-Shop> http://www.gnipsel.com/linuxcnc/examples/cl-turret.zip
[10:11:47] <JT-Shop> an example
[10:21:23] <cradek> R2E4: you hook them up in your hal file
[10:21:41] <cradek> R2E4: I suggest you use axis.N.amp-enable-out instead of halui.machine.on
[10:31:37] <R2E4> To turn on the machine?
[10:31:55] <cradek> yeah that's the machine-on output
[10:32:54] <R2E4> ok, so you cannopt connect signals in the gui? you have to edit hal file to do that?
[10:33:49] <R2E4> I mean when you add contact to a rung, you have to edit hal file to connect a signal to that contact.
[10:34:40] <cradek> yes, classicladder is just another hal component. you hook up its ins and outs like any other.
[10:39:24] <R2E4> so classicladder.0.in-00 would be %I0 in the gui?
[10:41:41] <cradek> yes
[10:43:43] <R2E4> cool, thanks
[10:45:08] <cradek> hm, I can't figure out how to run demo_sim_cl anymore in master
[10:45:49] <cradek> oh hm, found it under parport
[10:47:45] <emcPT> To those that we envolved in the discussion, we made a component to manage the issue. It is currently under testing, but it basically works like cradek sugestion.
[10:48:02] <cradek> yay
[10:48:56] <emcPT> The worst case is when the user presses the power on right after of estop, in this case the machine fails due to a ferror, that now we are using much smaller
[10:49:48] <emcPT> I think I cannot prevent the user from pressing the power on, or I do not have control over the power on (like disabel the button until a condition is meet)
[10:49:49] <cradek> you should use the estop loopback to disallow machine-on until it's ready
[10:50:18] <emcPT> will try to understand it
[10:50:21] <emcPT> thanks
[10:54:32] <R2E4> In ladder logic, when an N/O contact is closed then the output on the rung is energized, and when you open the contact the output de-energizes. Is this not how it works?
[10:55:34] <R2E4> I got it to turn on but my expected behaviour when I opne the contact back up, the output should reverse.
[10:56:10] <R2E4> But its not doing it. I have a feeling what I will have to reverse the order and use an off component. correct?
[11:01:19] <cradek> I don't understand your question
[11:01:29] <cradek> perhaps a screenshot of your ladder would help
[11:01:52] <R2E4> just a N/O contact with an output.
[11:02:18] <cradek> you mean like ---| |------( )---
[11:02:21] <R2E4> While the N/O is closed I want the output to be on until the input is opened again.
[11:02:27] <R2E4> yes
[11:02:38] <cradek> yes then the output will follow the input
[11:03:40] <R2E4> unless.... it is halui.machine.on, I know you told me not to use that but I am learning and haven't figured out axis.N.amp-enable-out
[11:04:14] <cradek> well it doesn't matter what it's hooked to, if that signal is changing
[11:04:22] <cradek> you are doing something wrong but I can't tell what it is :-)
[11:04:34] <R2E4> hehe
[11:04:45] <R2E4> I kind of figured that.....
[11:04:53] <cradek> perhaps you have ---|^|-------( )--- which means activate on rising edge
[11:05:07] <cradek> or perhaps you have ---| |-------(S)---
[11:05:41] <cradek> I'm out of guesses
[11:05:50] <R2E4> --| |------------( )
[11:06:12] <cradek> does the --| |-- part go blue and not blue when you change the input signal?
[11:06:23] <R2E4> The rung is turning pink when I close the contact. Normal?
[11:06:28] <cradek> er pink
[11:06:36] <cradek> so yes
[11:06:48] <R2E4> The whole rung turns pink
[11:06:52] <cradek> so where are you seeing a problem?
[11:07:04] <R2E4> its not turning off.
[11:07:08] <cradek> what isn't
[11:07:13] <R2E4> The machine
[11:07:24] <R2E4> the on/off button in the gui
[11:07:25] <cradek> the pink line, or the hal pin, or what
[11:09:23] <R2E4> The on/off button changes to the on in the gui when I hit the input, but when I release the input it stays on.
[11:15:17] <cradek> I suspect this isn't going to be a problem with your ladder output not working (and you should check it with halmeter) but something about the way you've got things wired up. Use halmeter and friends to narrow down the problem.
[11:27:11] <R2E4> OK, its only two lines
[11:27:33] <R2E4> net power-1-in hm2_5i25.0.7i77.0.0.input-00 classicladder.0.in-00
[11:27:43] <R2E4> net power-1-out halui.machine.on classicladder.0.out-00
[11:30:04] <pcw_home> does power-1-in change as expected
[11:30:11] <pcw_home> ?
[11:31:16] <R2E4> I am checking, but the output turns on si I would assume it does, problem is when I release input, output doesnt turn off
[11:31:31] <cradek> halui turns machine on when it gets a rising edge
[11:32:37] <cradek> I don't understand the big picture of what you are trying to do
[11:32:41] <R2E4> power-1-out turns off, but machine does not
[11:32:50] <cradek> I can see you misunderstand how those halui inputs work
[11:33:00] <cradek> but what is the big picture? the problem you are trying to solve here?
[11:33:49] <R2E4> I have a external circuit with latching relay, when the relay is on in0 I want the machine to turn on, when the input opens I want the machine to turn off.
[11:35:18] <cradek> what does the state of the external circuit tell you? what runs this relay?
[11:35:53] <R2E4> pushbutton on my control panel, latches external relay, an off pushbutton unlatches it
[11:36:47] <cradek> you do not need an external relay for that function. hook the on button to halui.machine.on; hook the off button to halui.machine.off
[11:37:01] <cradek> that is how halui is meant to work
[11:37:50] <R2E4> ok, so I had it right just didnt know how the halui.machine.on /off worked. So it needs rising edge t turn off also.
[11:38:47] <cradek> sure but you're making it very complex for no advantage I can see
[11:39:01] <R2E4> I just purchased an 7i84, so I/O is not a problem but, my way takes 1 input.
[11:39:26] <cradek> and a relay and a power supply for the relay
[11:39:34] <R2E4> I was just trying to cut down on I/O, but now I do not need to but, it is also a learning experience.
[11:40:48] <cradek> but sure you could do it in ladder. you'd trigger on rising and falling edges of your relay signal, and turn (for one direction) halui.machine.on ON until you see the halui.machine.is-on feedback, then turn it back off. same for the other direction.
[11:41:28] <cradek> that is the fully correct solution, because halui is not realtime so you have to wait for it to see and respond to your input signals
[11:41:28] <R2E4> yes, but I allready have that on my panel I am building. I also wanted extra contacts that symbolizes power on for other logic.
http://irmtl.com/LinuxCNC/VM40/vm40panel.JPG bottom right is the relay logic
[11:43:11] <R2E4> ah ok... I can do it with the pushbuttons directly. HAve an out put follow, so I can turn on the external relays.
[11:43:24] <cradek> yeah either way
[11:45:30] <IchGuckLive> hi all B)
[11:45:48] <Deejay> hi IchGuckLive
[11:46:09] <IchGuckLive> ;-)
[11:46:57] <R2E4> pcw_home: Is there an issue with using a 10ft db25 cable for 5i25 to 7i77?
[11:47:40] <IchGuckLive> R2E4: 10ft is ok but the speed is on6ft
[11:47:58] <IchGuckLive> i tryed 15 feet on my steppers
[11:48:19] <R2E4> thats step and dir, I am using servos
[11:48:45] <pcw_home> Normally no but watch out for ground loops
[11:48:46] <IchGuckLive> therfor the hint is the sign quality
[11:49:21] <R2E4> Powered from same source, so ground loop should not be an issue.
[11:49:40] <R2E4> Grounded same star ground theoretically
[11:49:44] <pcw_home> ground loops are always a problem...
[11:50:15] <R2E4> Gnds in the same machine?
[11:51:07] <pcw_home> the problem comes from servo and spindle drives mainly
[11:51:08] <pcw_home> (especially if the drive does not have differential analog inputs)
[11:51:44] <R2E4> IF I use the same ground connection as the drives, should be ok.
[11:52:02] <pcw_home> Nothing is GND at 10 MHz
[11:52:13] <R2E4> haha, I'm pretty far from there, I am having trouble turning on the machine with an input....lol
[11:53:54] <pcw_home> Servo and spindle drives generate high voltage square waves
[11:53:56] <pcw_home> into a large capacitance to ground (motor winding/GND capacitance)
[11:54:31] <R2E4> ah!
[11:54:49] <R2E4> Filters help?
[11:54:51] <pcw_home> this causes high frequency noise spikes on the "GND" of the drives
[11:56:20] <pcw_home> these noise spikes can travel down the DB25 cable and if of enough magnitude can trigger errors
[11:56:22] <pcw_home> the longer the DB25 cable, the higher the likelihood of this happening
[11:56:54] <R2E4> ok, I can use existing cable then....
[11:58:02] <pcw_home> there are things to do if you have this problem. the way to think of gnd noise is all gnd is just a big inductor
[11:58:04] <pcw_home> so you want more turns on the noise source and less turns on the critical sections
[12:00:20] <archivist> or hide a problem in a screened box, may need more than one box
[12:01:41] <pcw_home> I'm not saying you will have these problems with a 10 foot cable, just that your margins
[12:01:42] <pcw_home> get lower so some remediation may be needed (usually common mode chokes in a few critical locations)
[12:01:44] <pcw_home> or if really severe, a 7I77ISOL which galvanically isolates the 7I77 from the PC
[12:08:04] <R2E4> Thanks, I will keep an eye out..... or scope out.....
[13:06:16] <R2E4> I am trying to get rising edge of input to turn on Halui output and the trailing edge of same input to turn off halui output. Is this possible?
[13:09:12] <skunkworks> umm.. wouldn't that work as is?
[13:09:26] <skunkworks> or different inputs?
[13:10:44] <IchGuckLive> R2E4: toggle on both ege
[13:11:23] <IchGuckLive> R2E4: what is the main goal you want to reatch on this act
[13:13:02] <IchGuckLive> whaow a hard night on the channel as i read the logs lots of new people
[13:13:35] <IchGuckLive> Night as europ Timezone
[13:13:56] <R2E4> What I was discussing with cradeearlier. one input to turn on machine, when that input goes false turn it off.
[13:14:37] <IchGuckLive> halui.mashine_off halui.mashine-on
[13:14:52] <R2E4> I cant use same input for rising and trailing.
[13:15:23] <IchGuckLive> net extmashineon input halui.mashine-on
[13:15:45] <IchGuckLive> then use input-not to get it off
[13:15:49] <R2E4> oh wait, assign same ladder designation one to rising and one to trailing?
[13:15:54] <IchGuckLive> or the other way
[13:17:46] <IchGuckLive> net extmashineon input halui.mashine-on
[13:17:47] <IchGuckLive> net extmashineoff input-not halui.mashine-off
[13:18:31] <R2E4> I was trying it in classicladder.
[13:19:50] <IchGuckLive> then use a logic gate
[13:21:11] <R2E4> I'll try it hal version
[13:21:30] <IchGuckLive> R2E4: do you got a pin that controls your F2 motion.enable
[13:22:15] <R2E4> HAven't got there yet
[13:22:51] <IchGuckLive> if you never have worked near SPS stay Halui ;-)
[13:23:05] <Tom_itx> mmm busy morning here
[13:23:23] <IchGuckLive> Tom_itx: i got also impressed by the logs
[13:27:22] <IchGuckLive> ok im off BYE
[13:30:32] <jthornton> R2E4, you get ladder sorted out?
[13:30:56] <Tom_itx> is ladder more efficient code wise than halui?
[13:34:25] <R2E4> no
[13:34:37] <R2E4> hehe, still working on it.
[13:36:41] <R2E4> I have it working in hal file.
[13:37:30] <R2E4> I wanted to try it in ladder, but couldnt figure out the logic. The halui outouts is not working like regular outputs.
[13:38:14] <R2E4> In the hal, turned it on with input and turned it off with notput....
[13:39:46] <R2E4> I'm getting there slowly....
[13:40:20] <cradek> http://timeguy.com/cradek-files/emc/ladder-powerrelay.png
[13:40:35] <cradek> here is how I added that to demo_sim_cl
[13:41:01] <cradek> of course it works badly when you turn machine-off using the gui, since your relay is now stuck in a state that doesn't reflect reality
[13:41:23] <cradek> this is why you should hook the two buttons to halui.machine.on and halui.machine.off directly, instead of having a latching circuit that can be latched in the wrong state
[13:41:48] <cradek> (since two pushbuttons don't maintain any state themselves)
[13:42:00] <cradek> other than that, this ladder works properly
[13:43:19] <R2E4> I have it with two lines in Hal file..... Thanks for doing that sim. I will study that. I tried something and it spit at me when I was trying to attach same output to different function
[13:44:39] <R2E4> You saying it could get out of sync? The actual latching relay being energized and in gui it thinks it is de-energized?
[13:44:50] <cradek> yes exactly
[13:45:05] <cradek> not just in gui - I mean the real actual state of the machine
[13:47:29] <cradek> using a latching relay setup to just send edges to some edge-sensitive thing is a bad mixture
[13:48:02] <cradek> if you hooked the two buttons directly, you could use the gui button OR the hard buttons in any order, and everything would always agree and work
[13:48:04] <R2E4> ok, I thought it was pretty clever myself....lol
[13:49:19] <R2E4> so both N/O buttons, one on, one off, was turns on, one turns off and relay following machine on for my other external logic.
[13:50:06] <R2E4> I'll do that... Thanks, that really clears it up now....
[13:50:07] <cradek> yes just hook the buttons to halui.machine.on and halui.machine.off, and the relay to halui.machine.is-on
[13:50:55] <cradek> stateless controls allowing you to have multiple places from which to control is called "the emc way" whose name should be updated
[13:51:20] <cradek> you can do the same thing by using incremental encoders for feed override type controls
[13:53:17] <cradek> I didn't realize the way your scheme would fail (poke hard button on, poke gui to turn off) until I built the ladder and played with it
[13:53:28] <cradek> so all sorts of lessons to learn :-)
[13:56:50] <R2E4> I was running through the logic in my head to try and figure out where it would fail.
[13:57:11] <cradek> do you see it now?
[13:57:15] <R2E4> yeah
[13:57:40] <cradek> you don't need to turn it off in the gui. something like a ferror would do that too.
[13:57:57] <cradek> so you'd get a ferror, amps would disable, and your "on" button would be dead
[13:58:23] <cradek> you'd have to bogusly guess to push the "off" button, and then the "on" button would start working again
[13:58:31] <R2E4> The external relays would think the machine was on when the gui could be off, so the machine would be in a uncontrolable state depending on what the external relay contacts were doing.
[13:58:44] <cradek> yep
[13:59:00] <R2E4> gotcha
[14:00:27] <R2E4> On your diagram, whats EMC-E?
[14:01:48] <Tugge> Hi all. I might get some stepper motor with encoder and now I'm thinking to replace my normal steppers with these new ones. How hard it is to add motion feed back from steppers to linuxcnc?
[14:04:16] <R2E4> with the SIM build, you dont need the cards right? re: 5i25 and 7i77
[14:18:02] <R2E4> While I am there, I might as well get the rest of the logic for the machine to be on and ready. When do the drives get enabled? When the machine gets turned on normally? And what do I do with the "Drives Ready" signal from the drives?
[14:18:44] <R2E4> Confirmed, 7i84 on its way today.
[14:37:36] <alex_joni> Jymmm: pong
[14:37:47] <Jymmm> hey
[14:38:51] <R2E4> That was a good game back in the day....
[15:29:54] <andypugh> Caption competition: Yes actually I am single, how did you guess?
https://picasaweb.google.com/lh/photo/mlp3305ZycCOg_PHjw-2JdMTjNZETYmyPJy0liipFm0?feat=directlink
[16:19:33] <Tom_itx> andypugh are you aging the wood?
[16:20:35] <Tom_itx> the caption will be more appropriate when you get the lathe mounted
[16:21:43] <CaptHindsight> where are all those women engineers and scientists hiding?
[16:22:23] <cradek> andypugh: did you say that some new cars could start by just injecting and sparking the correct cylinder(s), determined by some kind of position sensor that knows the state of the engine even while stopped?
[16:23:02] <cradek> andypugh: someone has told me this, and I don't see how it can work because you would be unlikely to have any compression.
[16:23:37] <Tom_itx> if it were just past TDC it might
[16:24:33] <CaptHindsight> the cylinder would need to have fuel and air in it already waiting to be ignited
[16:24:47] <andypugh> Tom_itx: Yes, ammonia fuming
[16:24:56] <cradek> well we have computer-controlled injectors now...
[16:25:01] <Deejay> gn8
[16:25:08] <andypugh> cradek: Yes, that is how the 1916 Fire Engine is started.
[16:25:51] <cradek> I'm talking about modern cars that can start themselves without the usual starter motor
[16:26:21] <andypugh> cradek: Won't work for Diesel, and not for normal petrol fuel injection (which injects into the exhaust port). It might work for a direct-injection petrol engine. But it would have to have stopped in the right place, I think.
[16:26:32] <cradek> I'm aware of the crazy hit-the-shotgun-shell-primer-with-the-hammer stuff in some old engines...
[16:26:49] <cradek> oh ok, maybe this is not really a thing then
[16:26:55] <cradek> I wonder where I heard it - just assumed it was you
[16:27:05] <Tom_itx> there was a 68332 project to control an engine a few years back
[16:27:13] <mozmck> Some aircraft engines I've seen use compressed air through the supercharger... so no starter motor! :)
[16:27:23] <mozmck> seen as in seen on the web
[16:27:57] <cradek> slick
[16:28:23] <Tom_itx> cradek,
http://www.diy-efi.org/efi332/links.htm
[16:28:26] <mozmck> maybe you were thinking of a steam engine :) just open the steam valve and it starts
[16:28:26] <Tom_itx> that was it
[16:29:40] <Tom_itx> i've still got a pile of books leftover from playing with that chip
[16:30:01] <Tom_itx> like 9 or 10 just for the µC
[16:31:35] <CaptHindsight> 68K's and multibus
[16:31:47] <uw> i still have my 68k
[16:32:03] <Tom_itx> i still have 3 of the 68332 boards
[16:32:45] <CaptHindsight> http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MC68332 still on the Freescale site
[16:33:03] <uw> prolly like $20 a piece
[16:33:12] <Tom_itx> you could order different microcode masks for it
[16:33:28] <Tom_itx> i think the 'good' one was G
[16:33:40] <uw> wonder if anything nowadays uses PLCC package anymore
[16:33:54] <CaptHindsight> trying to see what geometry it was? 1-3um?
[16:35:55] <Tom_itx> 2 of these
http://www.robominds.com/ and 1 of these:
http://www.users.qwest.net/~kmaxon/page/side/controllers_137.htm
[16:38:09] <uw> that second site...
[16:38:31] <uw> i dont know whats a farther step back in time, the boards or the site itself
[16:42:26] <uw> however like many dated websites, the documentation is incredible compared to sites of today
[16:43:13] <uw> and wow the links to component datasheets are even uptodate
[16:45:07] <CaptHindsight> http://www.users.qwest.net/~kmaxon/page/photo_gallery10_137.htm
[16:45:53] <uw> indeed
[16:46:04] <uw> dont let the site fool you (like i was)
[16:46:13] <uw> this guy has done some shit
[16:47:18] <Jeebiss> Are steppers pulled from a printer good enough to make a basic cnc rig?
[16:47:31] <uw> how big of table?
[16:47:44] <uw> big = size + weight
[16:48:13] <CaptHindsight> Jeebiss: a few people here do that for routers up to ~ 1m x 1m
[16:48:30] <CaptHindsight> also depends on what size inkjet
[16:49:03] <CaptHindsight> small 12" epson or 48 x 96 Gand
[16:49:03] <Jeebiss> CaptHindsight: most likely just desktop inkjets
[16:49:27] <Tom_itx> uw, he's got some amazing stuff on that site
[16:49:39] <Jeebiss> i might be getting a pretty good deal on some 36 inch plotters that i could rob parts on
[16:49:46] <uw> Tom_itx, i cant believe some of this stuff
[16:49:54] <CaptHindsight> inkjets are non contact and just move a <0.5Kg carriage back and forth
[16:50:17] <CaptHindsight> the smaller ones are belt driven
[16:50:52] <CaptHindsight> so don't expect them to be big enough to handle much load
[16:51:08] <Tom_itx> uw, find his inventory of machine tools and test equipment
[16:52:34] <uw> does anybody know who he actually is?
[16:52:41] <Tom_itx> sorta
[16:52:43] <Tom_itx> yes
[16:52:51] <Tom_itx> Kenneth Maxon
[16:52:56] <Tom_itx> in the Seattle area
[16:53:22] <CaptHindsight> http://www.users.qwest.net/~kmaxon/page/side/other5_137.htm
[16:53:27] <Tom_itx> he stays busy
[16:54:58] <CaptHindsight> frequents Tustin, CA and Wichita and doesn't seem to travel outside the US except for Canada
[16:55:30] <uw> so random, but really probably one of my fav sites
[16:55:41] <uw> thers another guy in germany who has a good one
[16:56:06] <uw> not what i expected either when looking at the site
[16:58:15] <Tom_itx> i bet his neighbors love him
http://www.users.qwest.net/~kmaxon/page/side/mill103_137.htm
[17:11:18] <uw> ugh i cant read this guys site anymore
[17:11:21] <uw> so depressing
[17:16:58] <CaptHindsight> has anyone seen a cnc controlled caulk gun? Something like a heavy duty syringe pump only for high viscosity fluids.
[17:18:06] <CaptHindsight> fluids with viscosity of 90W oil or more
[17:26:00] <Tom_itx> solder paste
[17:26:27] <Tom_itx> actually more brazing paste
[17:26:39] <Tom_itx> for assembly of steel parts
[17:29:02] <CaptHindsight> http://www.martin-smt.de/en/dispense-technology/products/dotliner.html
[18:32:07] <Tom_itx> can i invert a halui output signal or do i need to run it thru a 'not' component?
[18:35:16] <JT-Shop> output to a physical output or logical?
[18:35:45] <Tom_itx> logical
[18:36:24] <Tom_itx> physical in the end but further down the logic train
[18:36:44] <JT-Shop> use not then
[18:45:44] <JT-Shop> guy on the forum wants to hold 0.001" with a backlash of 0.005" with software backlash compensation
[18:48:20] <Tom_itx> good luck
[18:50:08] <JT-Shop> trying to singulate PC boards
[19:07:17] <JT-Shop> say goodnight Gracie
[19:24:14] <ries> Any java experienced user around to help me test something on a linux or windows box?
[20:04:23] <jdh> new use for a BeagleBoneBlack
http://tinyurl.com/pknwdbo
[20:08:47] <ries> jdh: cat's are great support...
[20:08:53] <ries> to always ensure that your tools keep warm
[20:09:31] <Tom_itx> spray it with static cling
[21:03:10] <Tom_itx> anyone have an example of using 'logic9' ?
[21:09:29] <Tom_itx> and other than the number of inputs how is it any different than 'lut5' ?
[21:10:07] <eric_unterhausen> well, for one thing "logic9" makes sense and "lut5" doesn't
[21:12:03] <Tom_itx> seem similar with the 'weight' values
