Prev: Convert Hex val to Dec val or Chr()
Next: Timer in a Standalone exe as a Service
From: Henning on 29 May 2010 20:02

"Mike Williams" <Mike(a)WhiskeyAndCoke.com> skrev i meddelandet
news:hts7p0$o0q$1(a)speranza.aioe.org...
>
> "Larry Serflaten" <serflaten(a)gmail.com> wrote in message
> news:hts1r1$kjo$1(a)news.eternal-september.org...
>> I'd find that hard to believe that a CNC machine would
>> take a 28 byte file and turn it into a 56 byte program.
>
> Personally I've never even seen a CNC machine. I do know vaguely know what
> one is, but I would not recognise it if I fell over it in a dark alley
> (!). However, as an "old timer" coming from an era where I used to write
> machine code for 8 bit processors (and at a time when 8 bit processors
> were at the cutting edge of technology!) I can easily visualise hardware
> that might use nibbles (4 bit values) rather than Bytes to represent
> machine instructions. As an example, one of the processors I used to code
> for (6502) had a total of just 252 (as I recall?) instructions and so its
> entire instruction set would fit into one byte, and it is not beyond the
> bounds of imagination that a specialised CNC processor might have just 16
> instructions (or perhaps just 16 instructions that the user was permitted
> to access). Or perhaps the CNC machine does use Bytes to represent machine
> instructions but allows only a "nibble's worth" of each byte for user
> programming? (I think I'll go with the latter until proven wrong!).
>
> Anyway, looking at the data the OP has just posted, in which the first set
> of data is apparently the hex representation of a 14 byte data set, it
> would appear that (according to the OP):
>
> 0E0E00000505000C20450164A5A5
>
> . . . after conversion and compilation becomes:
>
> 30453045303030303035303530303043323034353031363441354135
>
> . . . which at first glance seems to indicate that each "nibble" of the 14
> byte hex string has the decimal value 30 added to it, so that the 28
> nibbles of the 14 bytes (when each one is expressed as a decimal value,
> where of course in this specific case each decimal value would use two
> digits) is expressed as the 56 character string that the OP has shown.
>
> The only "fly in the ointment" in the specific scenario I have outlined is
> that the only nibbles which do not come out as expected (in the OP's
> posted examples) are those nibbles that exceed the decimal value 9
> (although I cannot see a "9" in the example posted by the OP so I cannot
> be sure that 9 is the "cut off point"). Anyway, in those cases there seems
> to be an extra 1 added (so that, for example, A becomes 41 instead of 40)
> which possibly indicates that there is a specific value in that range
> which is "reserved" and which is not available to the CNC programmer (a
> value that appears to be somewhere in the "nibble" range 7 to A judging by
> the data the OP has posted so far).
>
> Perhaps the OP can investigate this further, and possibly provide some
> more data examples which might make it easier for us to see what he is
> actually dealing with. If we get sufficient data then it should easily be
> possible not only to write some VB code that will perform a conversion
> from the hex bytes to the decimal string, but also to write VB code that
> will actually do the CNC machine compilation for him.
>
> Of course, being an "old timer" with a brain that is rapidly wearing out I
> could be entitrely wrong on this, but that's my best shot at the moment
> ;-)
>
> Mike
>
>

40 = Ascii value for @. Since we are only dealing with hex characters, 30-39
= 0-9, 41-46 = A-F.

/Henning


From: Henning on 29 May 2010 20:07

"GS" <gesansom(a)netscape.net> skrev i meddelandet
news:htrq19$5v9$1(a)news.eternal-september.org...
>I really want to say a large THANKS to everyone who gave their time and
>patience to helping me to come up with solutions for this project. Please
>know that in the beginning I didn't have much info to go on AND I knew
>absolutely nothing about working with Hex, Dec, or Asc.
>
> Now I'm a better VB6 programmer than I was before this project started.
> Thanks to you all for that!
>
> Since a few of you commented about the scant bit of info I provided in my
> OP, here's what I now know about this project...
>
> Background: (As known "after the fact")
> I wish I knew more of this from the beginning but that's the way it goes
> when working with clients who themselves don't know much about what
> they're trying to accomplish. (Hence, why they come to us!<g>)
>
> I have a CNC Machine program file manager app that began as an Excel addin
> and evolved to a stand-alone VB6.exe. This app provided users a unique
> means of identifying, organizing, and creating/editing CNC Machine program
> files on their PCs and across their networks. This replaced the many long
> hours CNC Machine programmers/operators spent standing at machine control
> panels keying in their programs.
>
> One of my clients has other automated equipment that they wanted to work
> with in a similar fashion, and so provided me with scant bits of info they
> obtained from the manufacturer about a 'desktop workaround' to using the
> equipment's control panel. I ran with this as best I could, despite the
> lack of info from my user OR lack of knowledge in the topic[s] on my part.
> Thus, I greatly appreciate your persistence and patience!
>
> User application:
> For proprietary reasons, the manufacturer wouldn't disclose the core
> details of how the equipment's operating system works. -No surprise here!
> They told my user to look in the manual for the MachineCodes required for
> various processes, how to use Excel to write programs, and explained how
> to pass this to the control panel via its RS232 port. (Modern machines
> have network connections added, making things much easier to work with.)
>
> How it works:
> The keys on the control panel convert MachineCodes to HexDigits.
> The equipment post-processes the HexDigits to their individual Ascii
> equivalent expressed as a HexDigit, which is what the operating system
> executes. (OSs use DOS6.2 in most all automated controllers)
>
> So my user can construct a machine program from MachineCodes listed in the
> manual, which use DecValues as identifiers. So the following DecString:
> "14,14,0,0,5,5,0,12,32,69,1,100,165,165"
> becomes the following HexString:
> "0E0E00000505000C20450164A5A5"
> which is saved in a program (ie: text) file and passed to the equipment
> control panel via RS232 port.
>
> The operator loads the file into memory and compiles it to executable
> code, then runs the program. Compilation returns the following execution
> sequence, which is the equipment's runtime version of the program.
> "30453045303030303035303530303043323034353031363441354135"
>
> The equipment, then, executes 'canned cycles' (macros, basically) as
> defined by this Hex representation of the Ascii values of each character
> in the HexString.
>
> Whew!
> So my thanks and appreciation goes to...
> Auric_ and Henning for spawning the concept for the Hex2Dec code.
> Helmut, for your Hex2Dec code sample to exactly dupe Excel's function.
>
> Mike, for raising the issue of reverse integrity of Helmut's code.
> Note that this aspect ended up being the primary function used
> to create programs.
> Derek and Henning for responding with solutions for handling this.
>
> Henning, for providing the hint to the Hex2AscHex solution.
> (And the sample 'try this' code, which I already figured out
> on my own before you posted it)
>
> The results:
>
> Function Hex2Dec(HexString As String) As String
> ' Builds a delimited DecString from a source HexString
> ' Use to reverse-engineer programs created at machine panel
> Dim i As Long
> For i = 1 To Len(HexString) Step 2
> Hex2Dec = Hex2Dec & "," & CStr(Val("&H" & Mid(HexString, i, 2)))
> Next i
> Hex2Dec = Mid(Hex2Dec, 2)
> End Function
>
> Function Dec2Hex(DecString As String) As String
> ' Builds a delimited HexString from a source DecString
> ' Use to generate new programs from MachineCodes guide
> Dim i As Integer, v As Variant
> v = Split(DecString, ",")
> For i = LBound(v) To UBound(v)
> Dec2Hex = Dec2Hex & Right$("0" & Hex$(Val(v(i))), 2)
> Next
> End Function
>
> Function Hex2AscHex(HexString As String) As String
> ' Converts a string of HexDigits to Ascii-Hex equivalent
> ' Use to verify 'expected' runtime sequence for a program
> Dim i As Integer, v As Variant
> For i = 1 To Len(HexString)
> Hex2AscHex = Hex2AscHex & Hex(Asc(Mid(HexString, i, 1)))
> Next
> End Function
>
> Since my user wants to use these as a 'Plugin' to my VB6.exe, I'll package
> them into a DLL and send it off for in-field testing. (Even though we all
> know that's no longer necessary<g>)
>
> Knowing this client as I do, I fully expect this to evolve to putting the
> MachineCodes for building DecStrings into a listbox where the user clicks
> each item to add to a textbox where the delimited string is built as items
> are added. Since this is a random process, I plan to suggest it as a
> future enhancement once they're satisfied with how it works. I expect it
> will also need some way to edit the resulting string as well, which may
> also lead to implementing a data store of DecString templates. In this
> case, I'll probably use a 2nd listbox so reordering can be done before
> building the final DecString.
>
> Please know that AFAIK, I owe y'all a debt of gratitude!
> regards,
>
> --
> Garry
>
> Free usenet access at http://www.eternal-september.org
> ClassicVB Users Regroup! comp.lang.basic.visual.misc
>
>

Please follow-up later with the outcome in the "real" world.

/Henning


From: GS on 29 May 2010 23:10
Hi Mike,
Thanks so much for your feedback. I will make responses inside your
reply text, but the first thing I want to clarify is that the subject
equipment is no a CNC machine as we would know one. IMO, it's an
automated gismo with a control panel than amounts to not much more than
a hand held calculator. Real CNC machines use CPUs, a rather robust
keyboard, and a real monitor for display. This machine has a LED for
display and a touchpad with predesigned menus that change depending on
which key is pressed. Its function is to drive servo motors to execute
its predefined tasks. That's it in a nutshell!

on 5/29/2010, Mike Williams supposed :
> "Larry Serflaten" <serflaten(a)gmail.com> wrote in message
> news:hts1r1$kjo$1(a)news.eternal-september.org...
>> I'd find that hard to believe that a CNC machine would
>> take a 28 byte file and turn it into a 56 byte program.
>
> Personally I've never even seen a CNC machine. I do know vaguely know what
> one is, but I would not recognise it if I fell over it in a dark alley (!).
> However, as an "old timer" coming from an era where I used to write machine
> code for 8 bit processors (and at a time when 8 bit processors were at the
> cutting edge of technology!) I can easily visualise hardware that might use
> nibbles (4 bit values) rather than Bytes to represent machine instructions.
> As an example, one of the processors I used to code for (6502) had a total of
> just 252 (as I recall?) instructions and so its entire instruction set would
> fit into one byte, and it is not beyond the bounds of imagination that a
> specialised CNC processor might have just 16 instructions (or perhaps just 16
> instructions that the user was permitted to access). Or perhaps the CNC
> machine does use Bytes to represent machine instructions but allows only a
> "nibble's worth" of each byte for user programming? (I think I'll go with the
> latter until proven wrong!).
>
> Anyway, looking at the data the OP has just posted, in which the first set of
> data is apparently the hex representation of a 14 byte data set, it would
> appear that (according to the OP):
>
> 0E0E00000505000C20450164A5A5
>
> . . . after conversion and compilation becomes:
>
> 30453045303030303035303530303043323034353031363441354135
>
> . . . which at first glance seems to indicate that each "nibble" of the 14
> byte hex string has the decimal value 30 added to it, so that the 28 nibbles
> of the 14 bytes (when each one is expressed as a decimal value, where of
> course in this specific case each decimal value would use two digits) is
> expressed as the 56 character string that the OP has shown.
>
> The only "fly in the ointment" in the specific scenario I have outlined is
> that the only nibbles which do not come out as expected (in the OP's posted
> examples) are those nibbles that exceed the decimal value 9 (although I
> cannot see a "9" in the example posted by the OP so I cannot be sure that 9
> is the "cut off point"). Anyway, in those cases there seems to be an extra 1
> added (so that, for example, A becomes 41 instead of 40) which possibly
> indicates that there is a specific value in that range which is "reserved"
> and which is not available to the CNC programmer (a value that appears to be
> somewhere in the "nibble" range 7 to A judging by the data the OP has posted
> so far).

As Henning states: 30-39 = 0-9, 41-46 = A-F are pretty much all that's
used. The string could be any length, based on the instructions it
carries (total available I don't know)

I don't know much about bits & bytes, but IMO, this string is only
displayed to indicate progress to the operator. I guess it's safe for
me to say that it has absolutely no resemblance to machine code, and so
I suspect it's intent is to mask what's going on under the hood.
Besides, the LED isn't large enough to display much data as we would
see on a real CNC machine panel.

From what my user tells me, each step of the program is reflected by
its highlighted portion of the string. For example, I'll use the hyphen
character to demonstrate what the operator see on the LED during
runtime.

Step1
-3045-3045303030303035303530303043323034353031363441354135
Step2
3045-3045-303030303035303530303043323034353031363441354135
Step3
30453045-3030-30303035303530303043323034353031363441354135
and so on...
>
> Perhaps the OP can investigate this further, and possibly provide some more
> data examples which might make it easier for us to see what he is actually
> dealing with. If we get sufficient data then it should easily be possible not
> only to write some VB code that will perform a conversion from the hex bytes
> to the decimal string, but also to write VB code that will actually do the
> CNC machine compilation for him.

Thanks so much for offering!

The sample strings were provided by my client. What I did not know at
the outset was the HexString was a product of the DecString. I only
discovered this after I read your 1st post and started looking at how
it was possibly designed (best guess at that point) to work, given what
little info from the user I had to work with. So in this context,
building the DecString turned out to be the primary step in the process
of building the HexString. So your post raised the most important issue
to the project. I'm so happy you made your point early on!

Neither of these strings have anything to do with the actual program
code, but merely serve as pointers to the machine as to what programs
to run and in what order to run them. As I stated, everything is
built-in and so there's no operator availability to 'invent' new stuff
for the machine to do. (ie: calculators only perform what functions are
built into them. So the same concept applies here!)

In this case, I don't believe any 'compiling' happens at all. All the
HexString does is pass which macros to run, which order to run them,
and probably some parameters too. So between 30-39 and 41-46, that
makes 16 possible combinations of up to 16 variations of each. I
suspect that the OS uses a code table that has predefined variations
which it uses to set up the runtime sequence for any program. For all I
know, the macro names could be associated with the Hex digits somehow.
Normal CNC macros/progs are typically named Like("O1001, O1002) or
Like("P1001, P1002"), depending on their usage. This is typical of
FANUC style OSs. Newer generation software use 8.3 naming same as we
used for DOS files. These are written and installed same as we write
wrappers or some such, and called acording to however the HexString is
constructed.

BTW, did you notice the Fanuc program files don't have file extensions?
When you browse a folder of these in Window Explorer all you see is:

O0001
O0002
O0003
O0010
...
and of course, the usual metadata associated with files. What my CNC
files manager app does is add user-friendly 'filespecs' to these files
so we can identify what we're looking at without needing a chart or map
to guide us. These filespecs (that's what my app calls them) were
designed to fit with NTFS file SummaryProperties, so they could be
viewed with the optional columns available in WE. Unfortunately, the
SummaryProperties are no longer viewable in WE on the new x64 OSs. My
app also embeds these as code comments inside the file so they follow
the file. This allows reading them via my app regardless of whether or
not the files are stored on a NTFS volume. So users can view this to
the right of the filename in WE or my app:

Filename Title Author Subject Category Keyword Comment
O0100 ... GS ... ... ... ...
O0101 ... AC ... ... ... ...

and so on. Most CNC machine controllers will show a filename & title,
but that's it. The length of the filespec values is not limited in my
app, but I expect WE will truncate any that exceed the lv limit. So
this might shed some insight as to why my client wants to use the
solution we developed here as a 'Plugin' to my CNC files manager app.
IMO it's a good fit!
>
> Of course, being an "old timer" with a brain that is rapidly wearing out I
> could be entitrely wrong on this, but that's my best shot at the moment ;-)

And a good shot it was! I'm an old-timer myself, retired since
12/31/2006.

Summary:
Doesn't seem like a very efficient deal to me, but I believe it has an
entirely different purpose that satisfies the oem's obsession for
security. (Hint: client is in the automotive equipment industry, so
everything is new top-secret technology, huh!<g>)

regards,

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc


From: Mike Williams on 30 May 2010 03:58
"Henning" <computer_hero(a)coldmail.com> wrote in message
news:hts9tr$1eb$1(a)news.eternal-september.org...

> 40 = Ascii value for @. Since we are only dealing
> with hex characters, 30-39 = 0-9, 41-46 = A-F.

Right. I missed that completely! Seems a very strange representation of the
output of a compiler though ;-) Must be something to do with the text only
input to the machine or something?

ike



From: Mike Williams on 30 May 2010 04:18
"GS" <gesansom(a)netscape.net> wrote in message
news:htskvl$672$1(a)news.eternal-september.org...

> I don't know much about bits & bytes, but IMO, this
> string is only displayed to indicate progress to the
> operator. I guess it's safe for me to say that it has
> absolutely no resemblance to machine code, and
> so I suspect it's intent is to mask what's going on
> under the hood.

Right. It's just that with you saying it was the actual output of a compiler
and because it was twice as long as the byte input I just assumed that it
must be four bit opcodes, because I know that 4 bit processors used to be
quite common many years ago, and I just "jumped into the water" without
first testing it with my toes and completely failed to notice what is now a
"really, really obvious" decimal representation of Ascii numeric digits ;-)

As it appears this morning, in the cold light of day, it seems that I
actually made quite a fool of myself (wouldn't be the first time I did that,
and I'm sure it won't be the last)! I had consumed quite a few glasses of
wine at the time though, and I'm sticking to that excuse ;-)

Mike





First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Convert Hex val to Dec val or Chr()
Next: Timer in a Standalone exe as a Service