Reading Input Pin States for Conditional GCode
-
@OwenD thanks, I'll try that when I get back to my computer.
Where is the end stop number lookup list?
I don't actually have end stops... It's a 3pos switch. Is there a better way to declare them?
-
@tenaja
The name of the endstop doesn't change, no matter what is connected to it.
You can look all the (with the current config.g) addressable parameters and variables under- settings, then
- general, then
- Built-In-Plugins
There you have to activate the object model browser plugin. After that, it appears under the settings-tab.
/Julien
-
@tenaja said in Reading Input Pin States for Conditional GCode:
I have tried a few things, but everything has given me an error. I've tried both of these methods for declaring my inputs:
M950 J1 C"!^e1stop" M950 J0 C"!^e0stop"
And everything I try to do to read them gives me an error. Clearly, I am missing the documentation that describes simple reading of the input value. Can someone point me to that?
Those lines are correct to set up those ports as general purpose inputs. They only need to be sent once, so they can go in config.g. To read them, use object model array sensors.gpIn. For example:
if sensors.gpIn[1].value = 1 ;Run This GCode for large material elif sensors.gpIn[0].value=1 ;Run This GCode for Small material else ;Run this GCode for nominal material
-
-
@dc42 ...for future readers, that gpIn is case sensitive! I tested it just to be sure, and sure enough, it fails with lower case.
Wherever I was reading about it, I could not tell if it was an i or an l, but it was neither... it turned out to be a capital I (capital i, not L). I had to do a ctrl-f search, and even then it was unclear.
-
Yes, meta commands are case sensitive.
The wiki here states otherwise, but that was written before conditional code came along and needs review
-
@OwenD Thanks for pointing that out. It is true for the average gcode that it's not case sensitive, but not so for the conditional gcode, correct?
-
I rather see the case sensitive nature eliminated.
I have seen many defend such behavior but imagine if that applied to the naming of things, like children for example.
Consider four sons named Frank, frank, franK, frAnk - a recipe for confusion to be sure.
Frederick
-
@Phaedrux
As far as I'm aware, the only thing that is case sensitive is object model names.
I don't think IF vs if makes a difference.
In a way the document is correct as these aren't "G Code" in the true sense, but as we are now referring to it as "conditional gcode" then confusing will arise. -
@fcwilt said in Reading Input Pin States for Conditional GCode:
Consider four sons named Frank, frank, franK, frAnk - a recipe for confusion to be sure.
Frederick
But of course only one of those names would be correct.
-
@OwenD said in Reading Input Pin States for Conditional GCode:
@fcwilt said in Reading Input Pin States for Conditional GCode:
Consider four sons named Frank, frank, franK, frAnk - a recipe for confusion to be sure.
Frederick
But of course only one of those names would be correct.
How so? Four sons each with a different name if names were case sensitive.
Frederick
-
@fcwilt
I was mainly just throwing out a bait, but I'll answer.
It's simply because language has rules, be it English or a programming language.
A persons name must be represented with a capital letter.
Frank, is a name. "frank" is an adjective.The use of uppercase letters in object names is for a good reason. Most programming languages have such conventions for readability among other things
.
I accept your point of view that being entirely case insensitive may seem attractive.
I just reject your example. -
@OwenD said in Reading Input Pin States for Conditional GCode:
A persons name must be represented with a capital letter.
But if case sensitive names had been the norm from the far past that "rule" you mention would not exist.
I reject your rejection.
Frederick