Reading Input Pin States for Conditional GCode

dc42

@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

tenaja

@ZipZap , your post gave me the information I needed to figure out, on my own, along with @OwenD help... basically what David handed me on a silver platter.

Thanks to everyone for their help! This forum has always been excellent.

tenaja

@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.

OwenD

Yes, meta commands are case sensitive.

The wiki here states otherwise, but that was written before conditional code came along and needs review

Phaedrux

@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?

fcwilt

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

OwenD

@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.

OwenD

@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.

fcwilt

@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

OwenD

@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.

fcwilt

@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