Devin Hughes writes:

> Hi Alexander,
>
> Thanks for confirming my suspicions. I have seen those definitions, and I 
> didn't think the capability was there. The machinetalk stuff is starting 
> (slowly) to make sense to me. I am using Hal Remote components already, and 
> they work very well for exposing small numbers of values and config 
> parameters, but I'm not sure how that would supply many, i.e., hundreds, of 
> values. Fantastic if it's possible.
Yes, it is indeed possible. In your case it might be useful to write a
HAL Python script to build you component with configurable number of
pins + connection to motion.

>
> The client side is your QtQuickVcp library backend. Speaking of which, I 
> did correct the unit issues we spoke about on github - I owe you a pull 
> request for those fixes. Anyhow, here are the actual use cases in
> mind:
I would appreciate your PR.

>
> 1) Offset table. Similar to the tool table, I wanted to be able to query 
> every offsets value (G54-G59.3) that can be presented in the GUI with their 
> respective X,Y,Z,A,....offset value - extremely helpful for debugging jig 
> coordinate systems on a physical machine. I was starting to hack around a 
> little trying to push those values in the vein of the tool table message 
> already defined.
I implemented something similar recently. Basically I used the
hal_storage component
https://github.com/machinekit/machinekit/blob/master/src/hal/user_comps/hal_storage.py
and created a script to dynamically create a HAL remove component with
matching pins.

For this purpose I also add the "pins" and "bind" property in
QtQuickVcp. If you set bind to false you don't need to specify the pins
in the UI. So you can use the "pins" property as model for a table or
list representation of the values.

>
> 2) A table presenting all NC variables and their current value. This helps 
> debugging "complex" logic and math routines written in NGC format. The 
> current solution is to use a message component and print the value when you 
> want, but I've really grown to like how a HAAS control for instance let's 
> you browse updated variables in a tabular method.
If you are happy with a fixed number of variables you can of course
expose them via motion-analog or digital pins. Or the other way is to
read HAL pins directly from the GCode. But this is works currently only
read-only.

>
> I think the offsets tables are more valuable, and lower hanging fruit. I'm 
> happy to slash my way around my local repo trying to get them passed out, 
> machinetalk is just a little new to me still.
Let me know if you need help. I'm working on a little Machinetalk series
for my blog that might helpful for you (still working on the first
article...).

>
> Best Regards,
> Devin
>
>
> On Thursday, November 3, 2016 at 2:39:40 PM UTC-4, Alexander Rössler wrote:
>>
>> Hi Devin, 
>>
>> Here are the values reported by the status service on the interp topic: 
>>
>> https://github.com/machinekoder/machinetalk-doc/blob/master/machinetalk-protobuf.md#emcstatusinterp
>>  
>>
>> Currently it does not report the values of any #50xx variables. 
>>
>> However, if you explain your use case we might find another way to solve 
>> your problem. 
>>
>> E.g. if you want to get a value from the GCode interpreter to a 
>> Machinetalk client you can use HAL remote. Create a HAL remote 
>> component, connect it to a motion analog/digital output pin and connect 
>> with any Machinetalk client-side binding. 
>>
>> What type of client do you plan to use (QtQuickVckp, pymachinetalk, 
>> node-machinetalk, WebVCP, custom, ...)? 
>>
>> Devin Hughes writes: 
>>
>> > Hello everyone, 
>> > 
>> > I'm stumbling my way through the machinetalk work, and I'm having a 
>> > disconnect in my mind. Is there a way to query the value of an arbitrary 
>> NC 
>> > variable (e.g., 5020) without making a custom protobuf message? A 
>> > parameterized query of some type? Is it even possible? 
>> > 
>> > Any guidance is appreciated. 
>> > 
>> > Thanks, 
>> > Devin 
>>
>>
>> -- 
>> Alexander 
>>


-- 
Alexander

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Reply via email to