Prev: Convert Hex val to Dec val or Chr()
Next: Timer in a Standalone exe as a Service
From: Mike Williams on 30 May 2010 04:30
"Mike Williams" <Mike(a)WhiskeyAndCoke.com> wrote in message
news:htt6vp$msu$1(a)speranza.aioe.org...

> . . . completely failed to notice what is now a "really, really obvious"
> decimal representation
> of Ascii numeric digits ;-)

There, I've done it again! I of course meant to say "hex representation"!
The effects of last night's wine seem to be taking longer to wear off than
usual ;-)

Mike




From: Henning on 30 May 2010 07:39

"Mike Williams" <Mike(a)WhiskeyAndCoke.com> skrev i meddelandet
news:htt7nk$njn$1(a)speranza.aioe.org...
> "Mike Williams" <Mike(a)WhiskeyAndCoke.com> wrote in message
> news:htt6vp$msu$1(a)speranza.aioe.org...
>
>> . . . completely failed to notice what is now a "really, really obvious"
>> decimal representation
>> of Ascii numeric digits ;-)
>
> There, I've done it again! I of course meant to say "hex representation"!
> The effects of last night's wine seem to be taking longer to wear off than
> usual ;-)
>
> Mike
>
>

Hmmm, I thought Englishmen only had beer or tea.. ;)

I guess it's like &H0E as &H3045 could be thought of as a call to a
subroutine. I also guess that will display as operation "0E".

/Henning


From: GS on 30 May 2010 16:20
Henning has brought this to us :
> "Mike Williams" <Mike(a)WhiskeyAndCoke.com> skrev i meddelandet
> news:htt7nk$njn$1(a)speranza.aioe.org...
>> "Mike Williams" <Mike(a)WhiskeyAndCoke.com> wrote in message
>> news:htt6vp$msu$1(a)speranza.aioe.org...
>>
>>> . . . completely failed to notice what is now a "really, really obvious"
>>> decimal representation
>>> of Ascii numeric digits ;-)
>>
>> There, I've done it again! I of course meant to say "hex representation"!
>> The effects of last night's wine seem to be taking longer to wear off than
>> usual ;-)
>>
>> Mike
>>
>>
>
> Hmmm, I thought Englishmen only had beer or tea.. ;)
>
> I guess it's like &H0E as &H3045 could be thought of as a call to a
> subroutine. I also guess that will display as operation "0E".
>
> /Henning

Actually, it could very well be exactly as you propose. There is no
reason at all why the raw string "3045" couldn't be the name of a
macro, regardless of how it was assembled. It could also be
Macro30(Param45). Who knows what logic the oem used!

What I did not post was that the client's sample runtime sequence
string had '00' appended to the end. In Hex that would be 3030 but I
suspect it's an internal flag to tell the OS the program is finished.
Thus, why I referred to it's construction as being 'compiled', meaning
the runtime string as opposed to what we know as compiling a project.
Sorry if I wasn't more clear about that when I mentioned that it uses
predefined macros. What I suspect is going on at the keypanel is that
when the user hits the 1st key the keystroke is recorded as "0E", the
next keystroke is recorded as "0E", and so on. AFAIK there is no
provision to reorder the keystrokes and so an erroneous input has to be
scrapped and a new one started. (Might seem weird to you & me but it's
typical menatality for the industry in question!) I'm surprised they
even provided my client a desktop workaround alternative to using the
keypanel!

Regardless how 'strange' the logic seems to us, it does appear to have
structure that provides flexibility and room to expand/extend its
capabilities. So to give credit where credit is due, I give them that
for their cleverness. At least they had the sense to build a dedicated
control panel rather than modifying something already commercially
available (ie: a Texas Instruments gizmo or some such device).

regards,

--
Garry

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


From: GS on 30 May 2010 17:06
Mike Williams wrote :
> "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

Hi Mike,

Well, I certainly don't think you made a fool of yourself. Your input
is helping me learn about Hex/Dec & bits/bytes, which I knew/know 5/8
of nothing about before starting this project.

Also, I apologize for not making myself more clear about my use of
'compile' in this project's context. As explained to Henning, I was
referring to the runtime sequence string. I realize I was implying
early on that the user was writing programs but during the evolution of
the project it became apparent to me that what he was really doing was
programming the controller for how he wanted it to executes its macros.
I failed to make this clear, and so if anyone made a fool of themselves
then it was me. I'm sure my lack of knowledge and experience with VB
will cause me to make a fool of myself in the future, but I'll try my
best to keep it to a minimum<g>!

On the side:
I saw your Goodbye post in the M$ NG. Since we've already initiated
ourselfs in this new neighborhood, I won't reply to that post but I do
hope we meet more often in this place.

regards,

--
Garry

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


From: Karl E. Peterson on 1 Jun 2010 17:34
on 5/29/2010, Larry Serflaten supposed :
> "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.

Unless it needs to be transmitted via a 7-bit (serial?) medium?

> 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.

Could be.

--
..NET: It's About Trust! http://vfred.mvps.org
Customer Hatred Knows No Bounds at MSFT
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Free usenet access at http://www.eternal-september.org


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