Prev: Convert Hex val to Dec val or Chr()
Next: Timer in a Standalone exe as a Service
From: GS on 29 May 2010 15:30
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


From: GS on 29 May 2010 16:05
Couple of corrections...

This line
"The equipment, then, executes 'canned cycles' (macros, basically) as
defined by this Hex representation of the Ascii values of each
character in the HexString."

should read
"The equipment, then, executes 'canned cycles' (macros, basically) as
defined by this Hex representation of the Ascii values of each
CHARACTER PAIR in the HexString."

Declared "v As Variant" removed from Hex2AscHex

--
Garry

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


From: Larry Serflaten on 29 May 2010 17:44

"GS" <gesansom(a)netscape.net> wrote
> 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"


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. If you write the
HexString to a file, you'd get a 28 byte file. If you look at the
byte values in the file as hexidecimal, you'd get your 56 byte string.

It would be far more efficient to use the 28 byte representation where
each command is a single byte, than converting it to a 56 byte version
where each command is two bytes.

What I suspect is going on is that, whatever method you are using to
view the program is converting the 28 bytes to their hexidecimal
values and showing it as your 56 byte string.

LFS


From: GS on 29 May 2010 18:40
Larry Serflaten has brought this to us :
> "GS" <gesansom(a)netscape.net> wrote
>> 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"
>
>
> 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. If you write the
> HexString to a file, you'd get a 28 byte file. If you look at the
> byte values in the file as hexidecimal, you'd get your 56 byte string.
>
> It would be far more efficient to use the 28 byte representation where
> each command is a single byte, than converting it to a 56 byte version
> where each command is two bytes.
>
> What I suspect is going on is that, whatever method you are using to
> view the program is converting the 28 bytes to their hexidecimal
> values and showing it as your 56 byte string.
>
> LFS

I don't know enough about bytes to take this up with you in an
intelligent manner, but I think I would tend to agree. Though, how many
bytes can a string character (0-9, A-F) have? Is it not only Hex if
it's used in Hex form during runtime? I believe the MachineCodes the
oem provides are just numeric identifiers that the user converts to a
string character representing a Dec val, or the Hex digit it becomes
later. Same goes with the runtime sequence. Geez.., they gave my user
instructions for how to write the programs using Excel functions! -I'm
sure that's not how they do it. When the DecString is entered in Excel
it's just Cell.Text. When the HexString is returned to the worksheet it
also is just Cell.Text. So when it gets to the equipment control panel
in a text file, it's still just plain text.

All I know is what my user tells me. In the case of this particular
equipment (not typical of any conventional CNC Machinery I've operated,
but typical of something one would find in my user's industry), I
suspect this is only what he can see via the UI, and so what goes on
under the hood is an entirely different thing. Since these machines
typically run DOS6.S OSs and have relatively small amounts of memory
and storage, it makes sense to me that they do a lot more efficient
processes than what it appears the manufacturer is disclosing at the UI
panel. I suspect that the entire process as described here is just a
decoy to divert away from what's really going on.

Fact remains, though, that the program files are extremely small text
files. What the equipment controller displays to the operator really
has nothing to do with what it's doing under the hood; -it's usually
just a progress indicator to the operator. Most CNC machines progs run
G-code, not this 'junk'. If I was designing the OS, I'd use lookup
tables and process string values on those tables. (Which is what I
suspect is really going on) The largest CNC program file I've ever seen
was just under 6kb, and it had over 1K lines of executable code plus
comments. My thinking is that the oem uses tables to convert keystrokes
to the machine code language, which it converts to machine language
during its so-called post-processing stage. All this stuff is 'canned'
in pre-built macros, and so it's not like the operator can 'invent'
anything new as can be done with a real CNC machine. This is
task-dedicated equipment that security-obsessed oems produce with what
they claim is their own proprietary 'machine language': -all of which
is a bunch of hooplah as far as I'm concerned. But hey, we have to give
clients what they want and so we put up with the associated 'nonsense'
as best we can!

regards,

--
Garry

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


From: Mike Williams on 29 May 2010 19:25

"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




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