Torch Breakaway and Torch Pulse
16 Jul 2020 00:00 #174786
by phillc54
Replied by phillc54 on topic Torch Breakaway and Torch Pulse
I didn't know the pin name...
#net ohmic:type <= motion.motion-type
#net ohmic:type => ohmicsense.motion-type-in
net plasmac:motion-type => ohmicsense.motion-type-in
Please Log in or Create an account to join the conversation.
- snowgoer540
- Topic Author
- Offline
- Moderator
Less
More
- Posts: 2388
- Thank you received: 779
16 Jul 2020 00:06 - 16 Jul 2020 00:07 #174788
by snowgoer540
Thanks, as always. I need to find a way to mail you some metric-volume-measurement-units of beer, or start you a go-fund-me or something.
I dont understand why we can get rid of the "ohmic:type". Every time I start to wrap my head around HAL, I get turned around. Also, Rod mentioned signals and pins. Stupid question, I'm sure, but how do you know which is which? I wish there was a visual or diagram or something to make this easier to understand. Maybe once it clicks, I'll make one...
Replied by snowgoer540 on topic Torch Breakaway and Torch Pulse
I didn't know the pin name...
#net ohmic:type <= motion.motion-type #net ohmic:type => ohmicsense.motion-type-in net plasmac:motion-type => ohmicsense.motion-type-in
Thanks, as always. I need to find a way to mail you some metric-volume-measurement-units of beer, or start you a go-fund-me or something.
I dont understand why we can get rid of the "ohmic:type". Every time I start to wrap my head around HAL, I get turned around. Also, Rod mentioned signals and pins. Stupid question, I'm sure, but how do you know which is which? I wish there was a visual or diagram or something to make this easier to understand. Maybe once it clicks, I'll make one...
Last edit: 16 Jul 2020 00:07 by snowgoer540.
Please Log in or Create an account to join the conversation.
16 Jul 2020 00:09 #174789
by phillc54
Replied by phillc54 on topic Torch Breakaway and Torch Pulse
ohmic:type is a signal name. Signal names are arbitrary and are only defined when you do a net command.
the pin_ names are defined in the component
the signal_name is whatever you want it to be
net signal_name pin_name => pin_name
the signal_name is whatever you want it to be
The following user(s) said Thank You: snowgoer540
Please Log in or Create an account to join the conversation.
16 Jul 2020 00:19 - 16 Jul 2020 00:20 #174791
by rodw
Replied by rodw on topic Torch Breakaway and Torch Pulse
think of a LCNC component as being a component or chip on the circuit board say a 555 timer
The pin is a leg on the chip.
By itself its not useful until its connected to another component.
Pins can be outputs or inputs.
So a signal is the arbitrary name you give when you do:So you have now connected a wire called my-sig to a leg on the motion chip ( to an output)
So now you have a wire you can connect it to as many different pins as you like just like you can daisy chain a wire in a circuit.
I added the -in to my pin name to tell me its an input so it expects to receive an output pin from another component.
the <= and => are optional and also arbitrary. they can be left out. BUt the way I've done it, it is obvious what output is connected to my-sig and equally as obvious which inputs that signal is connected to.
I like to always make my declarations on seperate lines but Phill likes to put the signal and the input and the destination all on one line. I found some more complex lines connecting several pins at once need to be redone when I wanted to do something else with one of the pins on the line.
The pin is a leg on the chip.
By itself its not useful until its connected to another component.
Pins can be outputs or inputs.
So a signal is the arbitrary name you give when you do:
net my-sig <= motion.motion-type
So now you have a wire you can connect it to as many different pins as you like just like you can daisy chain a wire in a circuit.
net my-sig =>plasmac-motion-type
net my-sig => ohmicsense.motion-type-in
I added the -in to my pin name to tell me its an input so it expects to receive an output pin from another component.
the <= and => are optional and also arbitrary. they can be left out. BUt the way I've done it, it is obvious what output is connected to my-sig and equally as obvious which inputs that signal is connected to.
I like to always make my declarations on seperate lines but Phill likes to put the signal and the input and the destination all on one line. I found some more complex lines connecting several pins at once need to be redone when I wanted to do something else with one of the pins on the line.
Last edit: 16 Jul 2020 00:20 by rodw.
The following user(s) said Thank You: snowgoer540
Please Log in or Create an account to join the conversation.
16 Jul 2020 00:22 #174792
by rodw
Replied by rodw on topic Torch Breakaway and Torch Pulse
and outputs must be connected to inputs. You would expect that connecting one output on a circuit board could let the magic smoke out if it was connected to another output pin...
The following user(s) said Thank You: snowgoer540
Please Log in or Create an account to join the conversation.
- snowgoer540
- Topic Author
- Offline
- Moderator
Less
More
- Posts: 2388
- Thank you received: 779
16 Jul 2020 00:22 - 16 Jul 2020 00:28 #174793
by snowgoer540
I think it's the fact that they are on two different lines that confuses me.is the same asis that correct? or does it need to be:It seems like "ohmic:type" isnt needed. So I'm not sure why it needs to be there?
Replied by snowgoer540 on topic Torch Breakaway and Torch Pulse
ohmic:type is a signal name. Signal names are arbitrary and are only defined when you do a net command.
the pin_ names are defined in the componentnet signal_name pin_name => pin_name
the signal_name is whatever you want it to be
I think it's the fact that they are on two different lines that confuses me.
net ohmic:type <= motion.motion-type
net ohmic:type => ohmicsense.motion-type-in
net motion.motion-type => ohmicsense.motion-type-in
net ohmic:type motion.motion-type => ohmicsense.motion-type-in
Last edit: 16 Jul 2020 00:28 by snowgoer540.
Please Log in or Create an account to join the conversation.
- snowgoer540
- Topic Author
- Offline
- Moderator
Less
More
- Posts: 2388
- Thank you received: 779
16 Jul 2020 00:26 #174795
by snowgoer540
Ok, Those examples make sense. So since Phill had made that signal in the other file, you can then hook many pins to it. I think I get it. I need to print this off and read it about 4,000 times.
Also the stuff being on different lines sometimes, and on the same line other times screws me up all the time
Replied by snowgoer540 on topic Torch Breakaway and Torch Pulse
think of a LCNC component as being a component or chip on the circuit board say a 555 timer
The pin is a leg on the chip.
By itself its not useful until its connected to another component.
Pins can be outputs or inputs.
So a signal is the arbitrary name you give when you do:So you have now connected a wire called my-sig to a leg on the motion chip ( to an output)net my-sig <= motion.motion-type
So now you have a wire you can connect it to as many different pins as you like just like you can daisy chain a wire in a circuit.
net my-sig =>plasmac-motion-type net my-sig => ohmicsense.motion-type-in
I added the -in to my pin name to tell me its an input so it expects to receive an output pin from another component.
the <= and => are optional and also arbitrary. they can be left out. BUt the way I've done it, it is obvious what output is connected to my-sig and equally as obvious which inputs that signal is connected to.
I like to always make my declarations on seperate lines but Phill likes to put the signal and the input and the destination all on one line. I found some more complex lines connecting several pins at once need to be redone when I wanted to do something else with one of the pins on the line.
Ok, Those examples make sense. So since Phill had made that signal in the other file, you can then hook many pins to it. I think I get it. I need to print this off and read it about 4,000 times.
Also the stuff being on different lines sometimes, and on the same line other times screws me up all the time
The following user(s) said Thank You: rodw
Please Log in or Create an account to join the conversation.
16 Jul 2020 00:27 #174796
by phillc54
That is correct, you need to give the 'net' a signal name so in this case is named ohmic:type
Replied by phillc54 on topic Torch Breakaway and Torch Pulse
or does it need to be:
net ohmic:type motion.motion-type => ohmicsense.motion-type-in
It seems like "ohmic:type" isnt needed. So I'm not sure why it needs to be there?
That is correct, you need to give the 'net' a signal name so in this case is named ohmic:type
The following user(s) said Thank You: snowgoer540
Please Log in or Create an account to join the conversation.
- snowgoer540
- Topic Author
- Offline
- Moderator
Less
More
- Posts: 2388
- Thank you received: 779
16 Jul 2020 00:31 - 16 Jul 2020 00:32 #174797
by snowgoer540
Replied by snowgoer540 on topic Torch Breakaway and Torch Pulse
Ok, sorry for hijacking, we can get back on topic. I'm bookmarking this so I can read it each night before bed lol
To get back on topic, we had one vote "yes" from Tommy for an error message:
To get back on topic, we had one vote "yes" from Tommy for an error message:
That seems reasonable.
Dunno, see what others think.1. Should there be an error associated with trying to pulse the torch and either the float switch or the breakaway (or both) is tripped? It might alleviate some inquiries here at a later date?
Last edit: 16 Jul 2020 00:32 by snowgoer540.
Please Log in or Create an account to join the conversation.
16 Jul 2020 00:38 - 16 Jul 2020 05:38 #174798
by phillc54
While we are exercising our democratic rights:
If we do an error message should it be a popup or one of the standard GUI error messages.
I should also mention the when I did the interlock I included the float switch as that also behaves as a breakaway when not probing.
I also included the ohmic probe but I am not 100% sure if it should be included.
Replied by phillc54 on topic Torch Breakaway and Torch Pulse
Ok, sorry for hijacking, we can get back on topic. I'm bookmarking this so I can read it each night before bed lol
To get back on topic, we had one vote "yes" from Tommy for an error message:
That seems reasonable.
Dunno, see what others think.1. Should there be an error associated with trying to pulse the torch and either the float switch or the breakaway (or both) is tripped? It might alleviate some inquiries here at a later date?
While we are exercising our democratic rights:
If we do an error message should it be a popup or one of the standard GUI error messages.
I should also mention the when I did the interlock I included the float switch as that also behaves as a breakaway when not probing.
I also included the ohmic probe but I am not 100% sure if it should be included.
Last edit: 16 Jul 2020 05:38 by phillc54.
Please Log in or Create an account to join the conversation.
Moderators: snowgoer540
Time to create page: 0.098 seconds