OH MY what a can of worms you are opening(;-)   REMEMBER there are huge volumes of VB that have been coded. Most of it runs things that the current users have no way of redoing.

IN realiality WHY even mess with them. THey are there and they work.  Needs better descriptors you say???

 NOPE I diasagree all they need is a good definition as to what they do and how to use them.

Take Gcode for example NOT ONE gcode has a descriptor built into the GCODE name.  YEt millions can read and write the code just fine. why because they are well documented and people LEARNED what they mean.


IF it is not broke please don't fix it. IT is way too late in the game to do that.

PLEASE be carefull in your endevors, (;-) TP

Ray,

   The docs I posted under Member docs for the VB stuff was ALSO from the Source Code that Art sent me, it was tested as to funciton, and for what had been depreciated, and added above and beyond the current Wiki........

it will save you some time, my friend,

scott

HimyKabibble,

I vote to go forward with aliases. If the original 'names' are retained to run legacy code, there is no logical objection.

Just having everything in one place and in some semblance of a similar format will be a huge step in the right direction. I hope you will release something like that as soon as it is assembled.

If you are accepting 'wish list' items, and if it is possible, can M codes be named or have aliases? If not, could a look-up table be created where descriptive names could be used that would then call the numbered macro?

And, although it does not seem like part of your responsibility, I'll just take advantage of the opportunity to throw out some more whining for serial or USB port bidirectional access. 

Ray,

   The docs I posted under Member docs for the VB stuff was ALSO from the Source Code that Art sent me, it was tested as to funciton, and for what had been depreciated, and added above and beyond the current Wiki........

it will save you some time, my friend,

scott

Scott,

Yup, I'm using that.

Regards,
Ray L.

Simpson,

I agree, no reason not to do the aliases - Old macros will still work for as long as the old calls are supported, and we can push people towards using the new ones.  Below is a sample of the format I'm using to document the function calls.

Don't think named macros will happen this time, though I'd sure like to see it myself.  In the meantime, you can get partway there:

MyBlivetMacro = "M978"
...
Code (MyBlivetMacro)

Not as good, but a small step in the right direction.

Regards,
Ray L.

"Assert an output signal". Why not just say "activate an output signal, or send an output signal. Seems to me that "Assert" will confuse the hell out of people. I've been writing VB code for many years, and when I first saw "Assert", I had to read through the description to make sure I knew what you were saying. Very confusing imo.

"Assert an output signal". Why not just say "activate an output signal, or send an output signal. Seems to me that "Assert" will confuse the hell out of people. I've been writing VB code for many years, and when I first saw "Assert", I had to read through the description to make sure I knew what you were saying. Very confusing imo.

Gerry,

When defining the behavior of a piece of hardware of software, "assert" has a very definite meaning: it makes it clear that the output will be driven to its active state.  With a Mach3 output, this might mean it's driven to a logic high, or driven to a logic low, depending on how that output is defined in Ports&Pins.  But, whatever its active state, it will be driven to that state.  Assert has a very definite and unambiguous meaning, and is a term commonly used in technical literature, such as chip data sheets, to define such things.  If I read something was "activated" or "sent", I would not know what that meant, as those terms are quite ambiguous.  There may be a few new terms you'll need to learn to read this document, but once you do, you'll never have any doubts as to what a function does, once you've read its description.

Regards,
Ray L.

HMM......
Ray, here is the challenge, so what would a dummy like me do, i would't even know where start looking
 for the definition......but don't let me fog up your progress.......I am sure you'll clarify as necessary.

I quess, just write at whatever level you wish, you have enough of a challenge!
RICH

Since I'm following this thread, I may as well make a nuisance of myself and chime in on this one also.

The difference between 'assert' and 'activate' is very clear in my mind thanks to the description provided and it should be obvious that a clearly defined distinction between the two will prevent many hours of trouble shooting and frustration in writing code for Mach.

I do not find the terms confusing, however, the different definitions do cause a conflict when the two terms are used for the same function. I have to agree that this inconsistency is confusing. When I read it, my first thought was 'typo'.

My vote would be to change the function name to 'AssertAnOutput()' in the interest of continuity and clarity, if the purpose of the function is an 'assertion' as described.

Assuming the big dogs are watching this thread, may I take advantage one again and ask if it is possible to change the Mach setting from 'step/dir' to 'PWM' for spindle control from within a macro. I have looked but not found such a function.

Thanks!

There may be a few new terms you'll need to learn to read this document, but once you do, you'll never have any doubts as to what a function does, once you've read its description.

Regards,
Ray L.

I don't really care how you word it, I can figure it out. But imo you're going to make it very confusing for beginners. just my 2 cents.