Laundry List of small Requests

[rflulling]

1. Add Reset Now button to interface.
   This may seem odd but after many manual updates especially when tuning first run configurations, this would be a big help, even if it also resulted in a confirmation. At the moment the only way to do this is to pop the Config.h file and save it with no changes, and I can get the reset prompt. As of right this moment I have realized I can add this as a Macro.

2. Add Axis Max button to each axis control set.
   For a while now many companies were competing to see who could make the most affordable smallest Machine. But as that Trend has now gone full reverse we are seeing larger and larger. Meaning it would be nice to tell the axis to move to its default max as well as default min or home. This is again most useful in a new build or testing. I have added a pile of macros to compensate for this as of writing this. Edit: was pointed out that right click on the preset button values grants me access to changing them. yay!

3. There may be a bug in the Firmware. M208 S1 Lower Axis Limits
   I have need to invert an axis. [Resolved] I have gotten most of the settings to work in one way or another, but only parts of. There doesn't seem to be a Normal (not obvious) way to do this. When attempting to create this function in the Config.g. The bug seems to be that on M208 Xnnn Ynnn Znnn where the value of nnn is anything over a "9" and the bit of the S flag is 1. This causes issues. If you flip the axis, and putting a multidigit number in "" results in a null value and the axis will not respond to commands. Though all other functions can be reversed or even ran as negative values.
   A) If M208 X110 Y0 Z0 S1,and M208 X0 Y125 Z110 S0, and M574 X0 Y0 Z0 S0: I get some very strange behavior like X and Z moving in strange zig zags, flipped axis controls and very often all drives respond as the same axis.
   B) If M208 X110 Y0 Z0 S1, and M208 X0 Y125 Z110 S0, and M574 X2 Y0 Z0 S0: X will home to the left , stop then go back hit the endstop and all is good. I can home all axis. But try to home Y on it's own or raise Z and they are now inverted and smash into the end stops.

4. Add function to web interface to recognize inverted axis?
   If an inverted axis is detected, reflect it in the web interface??
   I would also like to make a similar request of the RRF Config tool, but I am expecting the simple answer is that Duet has no say over that tool, and I can accept that answer if true. Edit: As of now some see an obvious way to do this and others such as myself do not, or rather what we have tried does not work.

5. Add button to toggle Heater Core.
   The presets do not help much and selecting a value, as this action is not saved and is not activated.
   -To get a value to activate the user must click through the Tool "Heater" label until the desired value is selected, and made active. I would like to Make the "Heater" cell, colored to reflect the state, and place a button next to active and standby as toggles. I would also like to add one more for disable. Edit: For now it is much simpler to manage this function from the S3D control panel.

6. Make values input to the Heater Active/Standby, sticky/saved.
   As the interface functions now, accidentally clicking the link even one extra time voids the value previously input or selected. This makes this part of the entire interface the most frustrating, and simpler to operate from say S3D.

7. Stepper data.
   I would like to see any stepper data being output if available, such as load and temp.
   Can be shown under Machine Properties or machine status. Edit: Impossible to add?
   -I have noticed that M305 Pnnn where nnn is anything from 100 to 109 will result in the identification of a driver and it's associated sensor pin. So clearly there is some kind of communication, though as an Idiot lamp on an old Honda?? It only comes on after a problem happens?? Is there any way around this??

8. If I send a command from S3D and it is acted on, the Web-interface does not reflect all changes.
   Case in point: Sent a command to Disable the heater core from S3D over USB. Web Interface still shows as active, though the temp is shown as dropping. Same is true if the core is heated by remote command.

9. Location of X and Y are not always shown correctly on the Machine readout.
   When commends are issued from the Web Interface, some are not show, and the readout will be inaccurate.
   When G1 X100 and G1 X10, only 10 is shown, rather than 110. This bug is inconsistent and I have not nailed down an exact circumstance this happens, though it does frustrate calibration.

[dc42]

As this is a DWC topic I'll leave most of these for chrishamm to reply to. However:

1. Add Reset Now button to interface.
   This may seem odd but after many manual updates especially when tuning first run configurations, this would be a big help, even if it also resulted in a confirmation. At the moment the only way to do this is to pop the Config.h file and save it with no changes, and I can get the reset prompt. As of right this moment I have realized I can add this as a Macro.

You can use the Emergency Stop button. It halts the printer, then resets it.

3. There may be a bug in the Firmware. M208 Axis Limits
   I have need to invert an axis. I have gotten most of the settings to work in one way or another, but only parts of. There doesn't seem to be a Normal way to do this. When attempting to create this function in the Config.h,The issue seems to be that anything over a "9" causes issues if you flip the axis, and putting a multidigit number in "" results in a null value and the axis will not respond to commands. Though all other functions can be reversed or even ran as negative values.
   If M208 X110 Y0 Z0 S1, M208 X0 Y125 Z110 S0, M574 X0 Y0 Z0 S0: I get some very strange behavior like X and Z moving in strange zig zags, flipped axis controls and very often all drives respond as the same axis.
   If M208 X110 Y0 Z0 S1, M208 X0 Y125 Z110 S0, M574 X2 Y0 Z0 S0: X will home to the left , stop then go back hit the endstop and all is good. I can home all axis. But try to home Y on it's own or raise Z and they are now inverted and smash into the end stops.

I am not aware of any bug in this area and I don't understand your description of the problem, in particular the "anything over 9" bit.

If you often need to invert an axis for a particular print, here is a simple way:

1. Reconfigure your printer and slicer so that X=0 Y=0 is in the centre of the bed. I do this anyway on my square printers, it allows me to use the same slicer settings for all of them (and my delta) because I don't have to configure different axis offsets in the slicer.

2. Use the M579 command to invert axes. For example, M570 X-1 M579 X-1 will invert the X axis while printing.

7. Stepper data.
   I would like to see any stepper data being output if available, such as load and temp.
   Can be shown under Machine Properties or machine status.

The stepper drivers don't report actual temperature, only if they are running too hot. The StallGuard load data is currently available only in the M122 report.

[deckingman]

@rflulling In addition to what @dc42 has written above, for "2" above you could simply change the head movement controls in DWC to give you movement in excess of your carriage length. Then, once the printer has been homed, hitting either the positive or negative movement buttons will lead to the carriage moving either to the axis maximum or minimum as configured in your configuration file. So for example, if your X maximum was 425 mm, change the X100 movement button to (say) 430.

I realise that this isn't exactly what you asked for but those movement buttons are relative, rather than absolute which is what you would need to go to axes maxima from any given start position.

[rflulling]

@dc42 , I don't often get a direct reply from the actual developer on the first try, on a new forum. So I want to be respectful.

E-Stop is still a valid and much needed Button as I have no other recourse other than power cycle to stop the printer from doing something abhorrent, like slamming into an end point and the motor grinding away it's life, or doing some other irreversible mechanical damage. However why is the e-stop a not magic fix for all issues? I do not want to stop and wait for the 20 second progress bar versus a quick reset for settings update when a quick 2 second reset is legitimately "all I need." Even a full on power cycle runs faster, like 3 seconds on average. -For now I can see a macro is literally only choice less I want to hand type the command every time, or run a faux edit on the config.h to trigger a reset.

To be fair the bug fix issue is likely a whole other issue that should be under another forum. However you do not need to take my word for it. Try a clean setup, and Copy Paste the settings I provided. Honestly just running a number larger than 9 on X will create chaos, when the M208 S flag bit is set to 1. -It looks as though there is a bug in how code reads the line, and gets confused if there are more than 1 digit after the Axis flag. It them tries to apply those other digits to other parts of the command and gets it all messed up.
-Try adding a negative value, or a value in quotes for even more hilarious and unpredictable behaviors.

Thank you for the suggestion on M579. I actually added that to my Config.g previously, as it is not generated by default by RRF config, and I thought it might be useful in tweaking later. Though it seems most use M92 for this function by way of very long floating point numbers. I think I have even seen that a formula is acceptable in one of the Firmewares used for controller cards. However I had not thought to try using this tool as a means to invert the axis.

Note: You may want to edit your reply, I am pretty sure that you did not mean "M570 X-1" as this would generate an error when an axis flag is provided on a heater fault detection command. I am betting that this was a typo, and you meant M579 X-1

I was able to resolve the inversion issue in a way I swear I had tried multiple times.
M569 P1 S1, M574 X2 Y0 Z0 S0, and of course both Homeall.g and homex.g required an edit to resolve the X-115 as default to X115

I have other issues in axis movement but for the moment I am not ready to assault them until all others are off the table.

As for the steppers, so you say they do not output any data normally? They have a list of error codes though right? Just not any accessible data?

[rflulling]

@deckingman , I am honestly not at all sure what you are telling me to do. Are you suggesting to go into the JS files and edit them myself? I really have no idea where to begin. Thus I posted the request here in hope the request might be considered.

Ok egg on my face, I had no idea I could right click those functions. But as I am thinking about your suggestion I tried.

Thank You I will make changes immediately.

[rflulling]

@dc42 ,Thank you for the suggestion of altering the printer and Slicer. I understand that companies like CNC Shark, also home to center. But as my employer has two machines that do this and it's a nuisance, as center is never absolute. I will pass on this option. Maybe later.

In addition I cannot easily just change the location of the switches.

I could tell the Home functions after G28 functions to then direct the X & Y axis to the center and G92 X0 Y0. However despite this working fine as in your application, or for any new user (much the same as making no change at all), it is no good for an established user. In my case I would have to edit contents of more than 30 profiles in S3D and this requires going into each one at a time, until all have been changed. Additionally it would complicate going back to the original Melzi controller if I should ever get it fixed or replaced.

The ultimate point of this battle in the code is keep the setup as OEM as possible so that I can keep all existing profiles, and backward compatibility Both noted above. But also so that I can share the final set up and instructions with others who have this machine or one of it's many rebranded and reskinned brothers and sisters, all sourced from Wanhao. So others can use the Duet2 cards with these machines if desired, and hopefully spend less time fighting everything.

[deckingman]

@rflulling said in Laundry List of small Requests:

@deckingman ,
................. Ok egg on my face, I had no idea I could right click those functions. But as I am thinking about your suggestion I tried.

Thank You I will make changes immediately.

Don't forget that to make the changes permanent you need to go to the settings page of DWC (left hand side, lowest item on the list), then click the big blue "Apply Settings" button at the bottom of the page.

[dc42]

@rflulling said in Laundry List of small Requests:

To be fair the bug fix issue is likely a whole other issue that should be under another forum. However you do not need to take my word for it. Try a clean setup, and Copy Paste the settings I provided. Honestly just running a number larger than 9 on X will create chaos, when the M208 S flag bit is set to 1. -It looks as though there is a bug in how code reads the line, and gets confused if there are more than 1 digit after the Axis flag. It them tries to apply those other digits to other parts of the command and gets it all messed up.
-Try adding a negative value, or a value in quotes for even more hilarious and unpredictable behaviors.

Quite frankly, I don't believe there is a problem with "anything over 9". But if you can provide me with precise instructions, I am prepared to try to replicate what you are doing.

Negative values work, I use them in my M208 minimum settings.

Please note:

1. If you put a numeric argument in quotes, usually it won't be parsed and zero will be assumed. There are currently only a very few places in RRF GCode where numeric parameters in quotes are permitted; whereas string-valued parameters may always be quoted (and must be quoted in many commands).
2. If you set the minimum limit of an axis higher than the maximum limit, you can expect strange things to happen. Perhaps this is what you did when you used digits over 9 or negative numbers?
3. Your command "M574 X2 Y0 Z0 S0" says there are no Y or Z endstop switches. So no wonder you can't home Y.
4. The direction of the G1 S1 commands in the homing files and the selection of e.g. X2 vs X1 in the M574 command must be consistent. Please read https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareCartesianPrinter#Section_Homing_files if you haven't already.

Note: You may want to edit your reply, I am pretty sure that you did not mean "M570 X-1" as this would generate an error when an axis flag is provided on a heater fault detection command. I am betting that this was a typo, and you meant M579 X-1

Thanks for pointing this out, I have corrected it.

[rflulling]

@dc42

Some background. The machine I am working on is an Wanhao i3 Mini, operating on a custom Melzi controller. There are three 35mm N17 motors, and one 40mm on the Z. There are three end stop switches at zero, they are all SPST normal open, momentary. The bed moves from back to front, the switch being under the leading front of the bed. The X is mounted to an arm, that extends from Right to left, and the switch is on the head zeroing hard right. Z moves bottom to top zeroing at bottom. There is no Z-Probe. There is no need of it. The bed is mechanically leveled using 4x spring loaded thumb screws, and setting the head to 4 corners. In days past I had bad fans that created a lot of vibration on the head, and this made for an awesome bed leveling tool, as I could tune based on when the hum from the fan was transmitted into the build plate, and it worked great. Today however there is something dying on the Melzi board and I have chosen to switch out the board with a Duet2Maestro purchased from M3D durring their Crane preorder campaign, so I can assure I am not working on a clone. I have configured the MicroSD folder structure using instructions posted here: https://duet3d.dozuki.com/Wiki/Firmware_Overview#Section_SD_card_structure The firmware was installed to the folders from: https://github.com/dc42/RepRapFirmware/tree/dev/Driver then following notes on: https://duet3d.dozuki.com/Wiki/Installing_and_Updating_Firmware The files to the card were populated with files from: https://github.com/T3P3/Duet/blob/master/Duet2/SD Card Contents/SD_Card_Contents.zip then edited to weed out non applicable file with: https://duet3d.dozuki.com/Wiki/Firmware_Overview#Section_Duet_Generation_Num_2. Lastly setup was configured with: https://configurator.reprapfirmware.org/ and the files within hand tweaked following prior experience and information posted here: https://duet3d.dozuki.com/Wiki/Gcode

By observation your comment fits observable behavior.

1. If you put a numeric argument in quotes, usually it won't be parsed and zero will be assumed. There are currently only a very few places in RRF GCode where numeric parameters in quotes are permitted; whereas string-valued parameters may always be quoted (and must be quote in many commands).

Yes, this seems to be what is happening and this is why I said it is a bug. This causes OTHER axis to act up when they behave just fine in single digits.

2. If you set the minimum limit of an axis higher than the maximum limit, you can expect strange things to happen. Perhaps this is what you did when you used digits over 9 or negative numbers?

The RRF Config said to use X0 if I do not use anything other than a plain switch. If you use RRF to generate a generic profile, it will output M574 x0 y0 z0 s0. Please understand I am not a programmer and there are years of programmers efforts in this mess, it's not like any one took the time to organize this CNC to FDM dogpile of 50 years worth G/M code, and with so many opinions of how the codes should work there are obvious overlapping functions that some respect and others don't. -Understand that M569 P1 S1, M574 X2 Y0 Z0 S0 is one solution to the Inversion issue. It is not the problem. -I never said anything about having trouble homing Y, this is only an issue when the S flag bit is set to 1, on M208, and the X axis bit is set to anything greater than 9. If this is done then other axis develop strange an unexpected behaviors like acting in parallel, or performing logical axis flip flops with each home request.

3. Your command "M574 X2 Y0 Z0 S0" says there are no Y or Z endstop switches. So no wonder you can't home Y.

I am sorry, I am not quite sure what you are saying here. But I think this was in response to my comment about flipping the values in the home commands and yes it works fine right now, as described previously.

4. The direction of the G1 S1 commands in the homing files and the selection of e.g. X2 vs X1 in the M574 command must be consistent. Please read https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareCartesianPrinter#Section_Homing_files if you haven't already.

I keep tabs to https://duet3d.dozuki.com/Wiki/Gcode open at all times as reference until this is all wrapped up. I also have the original RepRap wiki book marked as from days passed in learning G-Code.

[dc42]

I think there is a misunderstanding between us of the terms "switch", "active high" and "active low".

• Any sort of endstop that detects when a carriage has reached the end if its travel and is connected to an endstop input is a "switch". That includes mechanical switches, optical switches, and Hall effect switches.
• Endstop switches come in two forms: "active high" and "active low". This refers to the logic level at the STP input of the endstop connector. With an active high switch, there is +3.3V on the endstop STP pin when it is triggered, and 0V when it is not triggered. With an active low switch, it's the other way round. There is an LED and pullup resistor between STP and +3.3V. A normally-closed mechanical switch connected between STP and GND produces an active high input. A normally-open mechanical switch connected between STP and GND produces an active low input. The S parameter in the M574 command tells the firmware whether the endstop input is active low (S0) or active high (S1).
• The firmware also needs to know whether each endstop switch is at the low or min end of the axis, or at the high or max end of the axis. For example, X2 means that the X axis has an endstop at the high or max end. Y1 means the Y axis has and endstop at the low or min and. Z0 means the axis has no endstop switch.

So your line M574 X2 Y0 Z0 S0 means that X has an endstop which at the high or max end of the axis (X2) and it is an active-low switch (S0). Y and Z have no endstop switches at all. As you are using normally-open switches, S0 is correct and S1 would be wrong. If you use S1 then the firmware will think that the switch is triggered when it isn't, and vice versa.

More at https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M574_Set_endstop_configuration.

HTH David

[rflulling]

@dc42 said in Laundry List of small Requests:

Thus I have tried to explain what I have as specific as possible. No argument to anything you said other than that i have never set the S flag on M574 to bit 1. -However RRF does, If I try to set this up, Then the bit must be set manually to S0 as the end stops are NOT active. Just mechanical termination.

The only S flag bit 1 I have referred to is on the M208 command. Thus setting the Low values.

• Any sort of endstop that detects when a carriage has reached the end if its travel and is connected to an endstop input is a "switch". That includes mechanical switches, optical switches, and Hall effect switches.
• Endstop switches come in two forms: "active high" and "active low". This refers to the logic level at the STP input of the endstop connector. With an active high switch, there is +3.3V on the endstop STP pin when it is triggered, and 0V when it is not triggered. With an active low switch, it's the other way round. There is an LED and pullup resistor between STP and +3.3V. A normally-closed mechanical switch connected between STP and GND produces an active high input. A normally-open mechanical switch connected between STP and GND produces an active low input. The S parameter in the M574 command tells the firmware whether the endstop input is active low (S0) or active high (S1).
• The firmware also needs to know whether each endstop switch is at the low or min end of the axis, or at the high or max end of the axis. For example, X2 means that the X axis has an endstop at the high or max end. Y1 means the Y axis has and endstop at the low or min and. Z0 means the axis has no endstop switch.

So your line M574 X2 Y0 Z0 S0 means that X has an endstop which at the high or max end of the axis (X2) and it is an active-low switch (S0). Y and Z have no endstop switches at all. As you are using normally-open switches, S0 is correct and S1 would be wrong. If you use S1 then the firmware will think that the switch is triggered when it isn't, and vice versa.

While I consider the issue of How to reverse the Axis closed. I will offer 4 sets of PDF later for examination. They will range from Default config, First functional, Bug expression, and fully calibrated.

All of this above I hope is taken in and apart from all requests for interface changes.

[fcwilt]

@rflulling said in Laundry List of small Requests:

Then the bit must be set manually to S0 as the end stops are NOT active. Just mechanical termination.

Hi,

What do you mean by that?

Frederick

[rflulling]

https://duet3d.dozuki.com/Wiki/Connecting_endstop_switches#Section_Connecting_different_types_of_endstop_switch

Microswitch

This applies to a bare microswitch, not to a microswitch on a board with a LED. Connect the switch between GND and STP (the outer 2 pins of the 3-pin connector). Note: this is not the same as on RAMPS.

We recommend you use the normally-closed contacts of the microswitches, which are generally the outside two connections on the microswitch, and set the signal polarity to active high (S1) in the M574 command. If for any reason you use normally-open microswitch contacts, you will need to set the signal polarity to active low (S0) in the M574 command.

@fcwilt said in Laundry List of small Requests:

@rflulling said in Laundry List of small Requests:

Then the bit must be set manually to S0 as the end stops are NOT active. Just mechanical termination.

Hi,

What do you mean by that?

Frederick

Also this: https://configurator.reprapfirmware.org

Generates the following code. Which incorrectly tells the hardware to expect a circuit.

Unfortunately, there are technically no errors, in the configurator or the code. But the S flag, bit 1 being on sets up the firmware for hardware that doesn't exist. See above on the Microswitch. Below works.

[fcwilt]

@rflulling

Sorry but I don't understand.

You have specified a NC switch on X and that is what the generated code specifies.

Frederick

[rflulling]

It's ok, I am getting very distinct feeling of you can lead a horse to water, but you cannot make him drink, since coming here. I explain things over and over and more often than not the replies have nothing to do with the concern and more with the confusion of those reading.

Sorry but I don't understand.

For the configuration, the Active high switch must be tagged or the X2 will not be generated. If using the configuration. Simply setting the end stop high only flips the axis in the Home functions. So the solution is to remove the S1 and change it to an S0 as it should be for my configuration. -I did not write any of this code, the firmware, or the configurator. I cannot change how it behaved, only customize the results so that they do what I need.

I am not indulging any one any further on this side topic as it has gone off the rails from the original post regarding the Web Interface.

[fcwilt]

@rflulling

I have built five printers using Duet products and they all work and I never needed any help getting the end stops setup.

You stated "Then the bit must be set manually to S0 as the end stops are NOT active. Just mechanical termination"

Active High/Low in the config tool applies to simple switches. A NC switch is active high. A NO switch is active low.

If you want Active Low you can select it in the config tool.

Frederick

[deckingman]

I doubt this will be any help but I don't understand either.

I think the issue is that @rflulling is getting confused by axis min (low end) and axis max (high end) with switch type active low and active high. The terms are being used interchangeably by statements like this " Simply setting the end stop high only flips the axis in the Home functions. " ........which makes no sense at all.

@rflulling To recap. X1 will tell the firmware that the switch is physically positioned at the low end of the axis - i.e at or close to Xmin. X2 will tell the firmware that the switch is physically fitted to the high end of the axis - i.e at or close to X max. The S parameter is used to tell the firmware what type of switch it is as DC42 explained above. If the switch type is normally closed and connected as it should be, then use S1. If the switch type is normally open, the use S0.

The type of switch cannot affect the direction of homing but we are all confused because that is what you seem to be implying happens.

Or to put it another way, the configurator and the files in generates work for everyone else so it's hard for us to believe that there is a bug, which is what you are implying.

EDIt. It seems that I was typing this at the same time as @fcwilt so I didn't see his post.

[fcwilt]

@deckingman said in Laundry List of small Requests:

I doubt this will be any help but I don't understand either.

Well that's a relief. I read his posts more than once and simply could not fathom exactly what he was thinking.

I think that this statement he made "Then the bit must be set manually to S0 as the end stops are NOT active. Just mechanical termination" is at the root of the problem.

I would hazard a guess that he is thinking that end stop devices that actually generate a logic level are "active" whereas simple micro switches are not. But, again, that is just a guess.

Frederick

[dc42]

@rflulling said in Laundry List of small Requests:

For the configuration, the Active high switch must be tagged or the X2 will not be generated. If using the configuration. Simply setting the end stop high only flips the axis in the Home functions. So the solution is to remove the S1 and change it to an S0 as it should be for my configuration. -I did not write any of this code, the firmware, or the configurator. I cannot change how it behaved, only customize the results so that they do what I need.

I'm sorry, I can't reproduce that. I just set this endstop config:

The configurator generated this in config.g:

; Endstops
M574 X2 Y1 Z1 S0                         ; Set active low and disabled endstops

Which is correct.

[nhof]

OK so just to clarify on the M574 code because I think there is confusion about the terminology.

The M574 command has two parts. The first Xn Yn Zn describes the physical location of the end-stops: whether is it at the min or max travel of the axis (or whether it is not installed).

The second part,Sn, describes the logic level of the end-stop input pin when triggered and is described by the terminology 'active [low/high]' The terminology can be a bit confusing but here is a breakdown for the function of standard microswitch endstops:

For a Normally Closed (NC) switch, the circuit is connected through the switch until it is pressed, so it will work as follows:

• When switch is not pressed, STP pin is shorted to GND through the switch, resulting in a STP pin logic state of LOW.
• When switch is pressed during homing, the STP to GND connection is broken, so STP is pulled hi through the pullup resistor. Thus a NC switch will result in an 'active high' (S1)signal on the STP pin.

For a Normally Open (NO) switch, the circuit will not be connected until it is pressed:

• When switch is not pressed, STP pin will be pulled HIGH through the pullup resistor.
• When switch is pressed during homing, STP pin will be shorted to GND through the switch, resulting in a STP pin logic level LOW. this is 'active low' (S0)

So 'active high' and 'active low' do not refer to which end of the axis the switch is installed on, but rather the logic level of the STP pin when triggered.

So an example config lines might look something like this:
M574 X2 S0 'active low' NO switch connected to X endstop input. X switch is physically installed at the max travel point of the X axis.
M574 Y1 S1 'active high' NC switch conneted to Y endstop input. Y switch is physically installed at the min travel point of the Y axis.
M574 Z0 S0 no 'Z' home switch is installed.

We may just be getting the logic level high/low confused with the axis position high/low.