Host Engineering Forum

General Category => Do-more CPUs and Do-more Designer Software => Topic started by: oliviagreene on September 19, 2019, 04:17:12 AM

Title: I do not understand intended behavior
Post by: oliviagreene on September 19, 2019, 04:17:12 AM
Previous content edited due to site terms violation. 
Title: Re: I do not understand intended behavior
Post by: Controls Guy on September 19, 2019, 10:24:00 AM
All rings in a block have to be delineated from the previous with some form of a STR instruction, except the first.  That's how DMD knows where the rungs break, and I bet that's what's confusing the paste operation.
Title: Re: I do not understand intended behavior
Post by: franji1 on September 19, 2019, 10:30:27 AM
It should be smart, and query whether you want the ST1 $On contact prepended to the output logic (or figure it out intelligently).

Should be easy to figure out when to do that.  I'm surprised this hasn't been caught sooner.

Title: Re: I do not understand intended behavior
Post by: Controls Guy on September 19, 2019, 10:34:07 AM
Or just fix the whole problem and just handle the $ST1s transparently and don't even show them.
Title: Re: I do not understand intended behavior
Post by: franji1 on September 19, 2019, 10:44:13 AM
Or just fix the whole problem and just handle the $ST1s transparently and don't even show them.

That's a different issue.  The issue is that $ST1 NO contact is NOT in the clipboard, but needs to be there (sometimes) when you paste it.

What you're talking about is whenever the $ST1 NO contact IS there, whether to draw it or not.
Title: Re: I do not understand intended behavior
Post by: franji1 on September 19, 2019, 10:46:04 AM
Or are you saying ALWAYS put an $ST1 on ALL rungs that are tied to the power rail (but then not draw them).  That could be done instead.
Title: Re: I do not understand intended behavior
Post by: ATU on September 19, 2019, 11:33:12 AM
If you are going to do that , make it an option. I don't want to find on a new DMD version that my programs mysteriously grow in size.
Title: Re: I do not understand intended behavior
Post by: franji1 on September 19, 2019, 12:19:49 PM
If you are going to do that , make it an option. I don't want to find on a new DMD version that my programs mysteriously grow in size.

Agreed.
Title: Re: I do not understand intended behavior
Post by: Controls Guy on September 19, 2019, 12:40:28 PM
Or are you saying ALWAYS put an $ST1 on ALL rungs that are tied to the power rail (but then not draw them).  That could be done instead.

Yes, this is what I meant.  It's something that has meaning for the parser, but not for the programmer.  If you show it on the screen, you're just burning visual bandwidth with no actual information transmitted.

I actually thought this was already in the task hopper.
Title: Re: I do not understand intended behavior
Post by: Controls Guy on September 19, 2019, 12:44:03 PM
If you are going to do that , make it an option. I don't want to find on a new DMD version that my programs mysteriously grow in size.

How is it [significantly] more space?  Almost every rung has to start with a STR now.  They don't have to add them on rungs that already have one, so the only place it adds an instruction would be the places you can get away without one now, like the first rung in a routine or following a left-rail box like FOR, NEXT, YIELD, etc.
Title: Re: I do not understand intended behavior
Post by: franji1 on September 19, 2019, 12:49:52 PM
For programs that are large, and if they use Stage programming, the implied ST1 contact may be quite prolific.  Many stages are just a few rungs long, many of them where the first rung is an OUT, a SET, or a TMR.

I have no idea how I will implement this.  It may just be best to do what I was originally planning if I was going to have to make the implied ST1 contact feature optional.  It would be easier to just make the paste be "smart".  You get the same net result (plus faster/less code).
Title: Re: I do not understand intended behavior
Post by: Controls Guy on September 19, 2019, 01:07:50 PM
You get the same net result (plus faster/less code).

Except for this part:  "It's something that has meaning for the parser, but not for the programmer.  If you show it on the screen, you're just burning visual bandwidth with no actual information transmitted."

I've despised that thing forever.  Losing it (and fixing AND above a JOIN) would be a boon.
Title: Re: I do not understand intended behavior
Post by: franji1 on September 19, 2019, 01:21:12 PM
I see your point.  Like I said, I have no idea how I would implement it (both the compiler side and the drawing side would need to support it).  It's a hack on both sides, regardless, especially with making it an option.
Title: Re: I do not understand intended behavior
Post by: Controls Guy on September 19, 2019, 02:19:31 PM
I see your point.  Like I said, I have no idea how I would implement it (both the compiler side and the drawing side would need to support it).  It's a hack on both sides, regardless, especially with making it an option.

Yeah, it's always the logically simple things that end up being a bear to implement.  OTOH, think of the brazilians of PLC programmer hours you'll save not having to enter or look at it!   ;)
Title: Re: I do not understand intended behavior
Post by: OrionHE on September 24, 2019, 12:38:15 PM
I feel like I'm seeing a different OP than the one everyone is responding to.