Material database about laserweb4

I like the mockup!

…

On Feb 6, 2017 10:35 AM, "jorgerobles" ***@***.***> wrote: @openhardwarecoza <https://github.com/openhardwarecoza>, @lautr3k <https://github.com/lautr3k>, or any other UI wizard: Material database editor is being crammed with all the options, any idea of a better layout? It's a bit tricky because must to be expandable too. Maybe a more traditional UI? [image: image] <https://cloud.githubusercontent.com/assets/1706080/22639660/653a12e8-ec4f-11e6-9824-7652c7df523c.png> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#39 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHVr26nmbMDjh43d9G__6VKPqUsb6qwtks5rZttbgaJpZM4K3OgM> .

Thanks! Now let me stop hijacking the thread!

…

On Fri, Feb 10, 2017 at 5:14 PM, gndprx ***@***.***> wrote: http://pencil.evolus.vn/ Pencil is another option and is open-source. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#39 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHVr2zGqcKmfgKnayTiBMZepKug8uIqtks5rbH7fgaJpZM4K3OgM> .

@jorgerobles Ok, great.
We will do some more testing, but from what I can see it is working as expected.
Now we need to go find some sheets of Branchcub Goat to test it with!

[gndprx]

Cool!

Sorry, been swamped and haven't been able to follow up on this. I did see your article and my suggestion is that we post it to the G+ group and ask for people to do some beta testing. I'll muck with it a bit today if time permits.

Looks great though.

[gndprx]

Also when you click edit on a preset, I think it should expand the group you are editing. If you click edit while it's collapsed it looks like nothing happens.

From a functionality standpoint, now that I've been through it once it works really well. Thank you for your hard work on this!

I am happy with Modals... No objections (:

On Nov 19, 2016 1:06 PM, "jorgerobles" [email protected] wrote:

Referred by #31 #31, I open
this issue to get further detail.

Proposal: This would affect two sections

On Settings: The Edit Material Database needs some space on screen. I
don't know if We go for a modal, or go for a whole new section without
workspace area. Anyways could show an editable datagrid (excel like...
http://adazzle.github.io/react-data-grid/index.html
http://adazzle.github.io/react-data-grid/index.html) that displays
the Name of the material, an Operation profile tag (Cut, Engrave, etc) and
then the Operation Speed, Operation Intensity, Operation Passes, and maybe
some more I don't know 😄

On CAM: There would be a wizard icon next to the operation selector,
and launch some modal that allows you to select the material/operation tag.
Then the operation settings will be overriden, like the way described on
Machine Profiles, allowing to tweak for the experts and so on.

@openhardwarecoza https://github.com/openhardwarecoza, @tbfleming
https://github.com/tbfleming any thoughts about this?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#39, or mute the thread
https://github.com/notifications/unsubscribe-auth/AHVr20T31WYPOJtuABWG3VQ9sONLovDtks5q_tgmgaJpZM4K3OgM
.

[tbfleming]

I can't think of an alternative to modals yet, so go ahead and do it.

[jorgerobles]

I'm modelling the state of the database. I don't know if use a plain dataset row (sqlite, mysql), or doing a tree document (mongodb). Also, I plan to store just the operation settings for each material, as different operations (could) have different settings

What do you think?

[
    {
        "uuid":"plywood_3mm",
        "material": {
            "name":"Plywood",
            "thickness":"3mm",
            "notes":"Standard Regular Plain Plywood, not thick nor thin."
        },
        "operations":[
            {
                "type":"Laser Engrave",
                "tag":"Engraving just a little",
                "settings":{
                    "cutDepth":"",
                    "laserPower":"",
                    "passDepth":"",
                    "cutRate":""
                }
            },
            {
                "type":"Laser Engrave",
                "tag":"Cut through",
                "settings":{
                    "cutDepth":"",
                    "laserPower":"",
                    "passDepth":"",
                    "cutRate":""
                }
            },
            ...
        ]
    } 
]

[tbfleming]

Is this going to be in a cloud service? Trees will be easier; a fully-normalized SQL schema for that data would need at least 5 tables: material, machine, material-machine, operation, operation-setting.

Nitpick: that's not a uuid. uuids have a specific format and are usually hidden from users: d134d8c5-0ccb-4a23-bc22-e6735e4de874

[arthurwolf]

No cloud !
Modern browsers have SQL capability ...

On Sat, Nov 19, 2016 at 9:05 PM, Todd Fleming [email protected]
wrote:

Is this going to be in a cloud service? Trees will be easier; a
fully-normalized SQL schema for that data would need at least 5 tables:
material, machine, material-machine, operation, operation-setting.

Nitpick: that's not a uuid. uuids have a specific format and are usually
hidden from users: d134d8c5-0ccb-4a23-bc22-e6735e4de874

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#39 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGpFULgXmEyR0Gj64sphassfc43U5KMks5q_1aJgaJpZM4K3OgM
.

Courage et bonne humeur.

[tbfleming]

Browsers tend to wipe local storage when you least expect it.

Preconfigured profiles for popular setups would probably ship built in.
Connected users, might be nice to opt into profile sharing... Eventually.

On Nov 19, 2016 10:10 PM, "Todd Fleming" [email protected] wrote:

Browsers tend to wipe local storage when you least expect it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#39 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHVr22elGEQEoAWz3Ga-nQGF8YSRG8XPks5q_1eSgaJpZM4K3OgM
.

[tbfleming]

In that case, it may be easiest to put it in a json file.

[jorgerobles]

Yes, I know is not a real UUID, just faking the data and was not sure what to use 😄 @tbfleming
Indeed right now is a json file, hardcode "required" in the associated reducer (not commited yet)

I asked for opinion about documental or relational database schema just for the same questions all of you exposed, but we need a efficent way to store the data. I slighty prefer documental, but relational is relatively easier to query, simpler table render/edit, etc (just my opinion, there's a bunch of against out there).

I suppose we need also an extra parameter in the data, because the operations depends heavily on the machine. My 3W diode needs 15 passes, full power, 800mm to cut through 3mm plywood, and a K40 needs once, maybe a couple. This could be just pairing with a Settings Profile tag ( @openhardwarecoza , is that what are you pointing to? )

About cloud/offline/client oriented application , my opinion is that in order to make LW useful/memory happy software we need to ditch the use of "in-browser" data storage, and moving to a client/server architecture, being client the part we are developing right now, and server, a local node server (like LW3 server) that should manage connectivity with an storage layer: File, DB or Cloud, but this may not be excluding with just loading a JSON file with the material database every time you boot on the application and/or relaying onto LocalStorage.

(But I'm concerned the use of LocalStorage should be managed carefully, because dumping/reading serialized data, and drains ram as there was no storage once loaded -- Ok, maybe only a couple of geeks will exhaust ram using the material database, if any)

So, to finish 😪 if all of you agree,

• By the moment I'm going to use JSON structure with the same pattern on settings: Initial Hardcoded profiles with Storage on LocalStore with [Export] , [Import] and [CRUD] actions.
• I will extend the schema with a machine_profile attribute that binds with the machine profiles. (Which could be an arseache because profiles could be deleted)
• I will try to implement the less complicated UI to edit the tree, but I'm going surely ask you for ideas, as is not trivial to build the finest way to fill this complex dataset

[tbfleming]

I will extend the schema with a machine_profile attribute that binds with the machine profiles. (Which could be an arseache because profiles could be deleted)

The redux way of doing this: multiple reducers listen for delete actions. e.g. The CAM's Operation reducer listens for Document deletes.

[jorgerobles]

WIP (not comitted yet)

• Launch from profiles panel
• Use top filter to select a machine profile. Current active machine profile is used.
• Ordered by Material=>Operations (Filtered by Machine profile, and sorted by operation type) Dobule click to expand material row
• Capable of handling multiple operation natures (distinct params each operation type)
• Use flexbox tables! 🤓

To do: (... A lot!) Handle State, Editing saved parameters, CRUD operations.

[jorgerobles]

I´ve pushed latest development about material database in my fork. I'm having trouble on several fronts so advice/help needed.

@tbfleming I've exposed (export) operation fields and operation types, so can be reused by the material database to retrieve the params, but I cannot use other input references (NumberInput) than exposed on operation.js NumberInput (namespacing?). I've slighty modified this component to keep it abstract enough (not hardcode conflicting styles).

Is there a way to connect to a subset of a state? I want to connect to a single Material to keep the component manageable.

• About this I want to rise a proposal of unifiying input components. I had started with settings "forms.js" inputs, but Operation Inputs are named the same and are not the same component interface.
• A second proposal is to try to minimize hardcoded styles if possible. I've done a fork of a nice flex table data (react-flex-data) but has horrible hardcoded borders, fonts, heights... and so on.

Thanks a lot!

[tbfleming]

@jorgerobles If you want, you can replace the styles in my components with class names. I used styles out of laziness.

function Foo(..., className = 'bar') {
    return (
        <foo ... className={className} />
    );
}

function MoreComplex(..., fooClassName = 'foo', barClassName = 'bar') {
    return (
        <foo ... className={fooClassName}>
            <bar ... className={barClassName} />
        </foo>
    )
}

About this I want to rise a proposal of unifiying input components. I had started with settings "forms.js" inputs, but Operation Inputs are named the same and are not the same component interface.

You may rename my components. e.g. NumberInput -> ObjectNumberInput since it operates on an object's field.

Does your editor support auto formatting? I use vscode's autoformatter (shift+alt+f).

[jorgerobles]

Thanks :) My idea behind unifying the inputs is not the name, but the abstraction of the component, so if we name NumberInput for use with numbers, with certain aspect or component interface, we should reuse that component in other part of the application as far as possible. Derived components should wrap this former to achieve their objetives (or simply renamed to reflect other nature of component as you pointed) Regards!

[tbfleming]

Be careful abstracting too far. e.g. if I strip out the field stuff from NumberInput, it looks like this:

function NumberInput({value, style, onChange, onFocus}) {
    return (
        <input type='number' step='any' value={value} style={style} onChange={onChange} onFocus={onFocus} />
    );
}

The only thing it does differently than plain input is set type and step, which isn't very useful.

[jorgerobles]

Until we decide to theme with bootstrap or materialize, then you could touch this atomic element with bs classes and then all the inputs are themed with few lines :)

[jorgerobles]

[jorgerobles]

[jorgerobles]

@openhardwarecoza, @tbfleming I've added a stub to pick material from the material database on Cam pane. Actually (WIP) only dispatch MATERIAL_APPLY(materialId, operationIndex).

When completed, should override the current operation settings (Could be done dispatching OPERATION_SET_ATTRS), but, what we do with thickness (is not present on operation data)?
Should OPERATION store be populated with MaterialId, OperationIndex applied for future use?

[tbfleming]

Thickness is weird since it will throw off machines which probe the top of material. Every solution I can think of has confusing downsides.

[jorgerobles]

Ok then, by now It will override operation params, and keep thickness cosmetic. It's ok?

--cosmetic is not unuseful, because users could keep it as a reference for their jobs anyways --

[tbfleming]

Sounds good. You can dispatch a single OPERATION_SET_ATTRS which includes all non-empty settings. Don't include empty settings or it will overwrite good values. Make sure OPERATION_SET_ATTRS number attributes only contain numbers, not stringified numbers.

[jorgerobles]

@openhardwarecoza, @lautr3k, or any other UI wizard:
Material database editor is being crammed with all the options, any idea of a better layout? It's a bit tricky because must to be expandable too. Maybe a more traditional UI?

[gndprx]

I almost wonder if it wouldn't be more useful to come at this the other way around. More from a "what do I want to do" with the "what material am I using" being the secondary question. I go to my laser with the mindset that I'm going to do a light engraving followed by a cut. Then I select my material and setup my operations accordingly.

I see this as a benefit where you could setup some common jobs that are pretty universal across materials or close enough that you could copy the default and tweak one or two settings to create a new material specific option. Copy being the big time saver as 75% of the settings will probably be the same with tweaks to power and feed only.

So something like this maybe:

{
	"id":"light_v_engrave",
	"name": "Light Vector Engraving",
	"operations":[
		{
			"machine_profile":null,
			"name": "Default"
			"type": "Laser Fill",
			"params":{
				"filter_fill":"green",
				"filter_stroke":null,
				"laser_power":"30"
				"passes":"1",
				"cut_rate":"1500"
                        }
		},
		{
			"machine_profile":null,
			"name": "Baltic Birch Plywood"
			"type": "Laser Fill",
			"params":{
				"filter_fill":"green",
				"filter_stroke":null,
				"laser_power":"40"
				"passes":"1",
				"cut_rate":"2000"
			}
		},
		{
			"machine_profile":null,
			"name": "Cast Acrylic"
			"type": "Laser Fill",
			"params":{
				"filter_fill":"green",
				"filter_stroke":null,
				"laser_power":"20"
				"passes":"1",
				"cut_rate":"1000"
		}
	]
}

[gndprx]

Then you could use something like this. The operation would drive the material selection dropdown. A default operation would be available to edit or copy to new and transfer over all of the default values to be edited.

Or better yet, rather than the left showing the default always, have it show the selected material settings since default would be one of the options in the dropdown anyway. Then you could tweak a single materials settings if needed by copying the selected material (does that make sense?) Say 3mm vs 5mm birch, you could copy the 3mm and up the number of passes for a cut and save a new one in a single step.

What app are you guys using for these awesome mockups

…

On Feb 10, 2017 4:30 PM, "gndprx" ***@***.***> wrote: Then you could use something like this. The operation would drive the material selection dropdown. A default operation would be available to edit or copy to new and transfer over all of the default values to be edited. [image: image] <https://cloud.githubusercontent.com/assets/8764001/22830136/66a33034-ef73-11e6-8ad1-bc6bf4a3336e.png> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#39 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHVr29kRnU_XHDUIRZvmBxCPyZ4oFh0Yks5rbHR0gaJpZM4K3OgM> .

[gndprx]

I used Balsamiq

[gndprx]

Lifted the existing CAM operations tab

A shame thats not free :( Love the mockup you posted (both because of Balsamiq but also the feel of the window

…

On Fri, Feb 10, 2017 at 4:32 PM, gndprx ***@***.***> wrote: I used Balsamiq — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#39 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHVr2-Krx5A91OqmR64lZN92UksEDWCuks5rbHTwgaJpZM4K3OgM> .

[gndprx]

Interesting. I just downloaded the desktop app and didn't pay anything.

[gndprx]

http://pencil.evolus.vn/

Pencil is another option and is open-source.

https://balsamiq.com/download/ says "About the Trial The trial <https://support.balsamiq.com/sales/evaluate/> is fully functional for 30 days. Afterwards, you'll need to buy a license <https://balsamiq.com/buy> to edit your work."

…

On Fri, Feb 10, 2017 at 5:12 PM, gndprx ***@***.***> wrote: It is free if you download it. I think the web version may cost. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#39 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHVr2-nEPB6asmaQD0ALnuiEAAa61FDnks5rbH5pgaJpZM4K3OgM> .

[jorgerobles]

@gndprx I like the mockup but I'm not sure if "changing the mindset" is a better option than the one is now running (I'm not against, simply found it a matter of taste)
Maybe setup a poll in LW G+, and let the crowd decide 😄

[gndprx]

Understood and I'm not expecting anyone to change on a dime. I'm just thinking in terms of workflow. Since you're designing your parts in the mindset of engrave and cut and ultimately your CAM operations are broken up into engrave and cut, why flip it around to setup your materials.

I'm finding that as I work with my machine, most of my operations are almost identical with only one or two small tweaks between materials so the ability to clone a particular operation and apply that single tweak would mean not having to start a new material from scratch and recreating your operation for the new material.

[gndprx]

And if it does go the route of material first, can we at least add an option to copy an operation to another material?

[jorgerobles]

Yes, we can :) El 10 feb. 2017 9:28 p. m., "gndprx" <[email protected]> escribió:

…

And if it does go the route of material first, can we at least add an option to copy an operation to another material? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#39 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABoIYLqLz7lUKNPoUW6TE3w8heuHpb6Nks5rbMhmgaJpZM4K3OgM> .

[jorgerobles]

@gndprx https://plus.google.com/113562432484049167641 people have spoken. Thus shall be done.

[jorgerobles]

@gndprx, @openhardwarecoza Reviewing the database scheme it will change as your proposal, and comes with a surprise 😄

The database no longer need to support "Materials" per se, is up to the user to name the Branch struct or Leaf struct as they wishes. So you could organize as Material->Operation, or Operation-> Material, keeping Name/Notes as free will fields to do whatever they want (LW will be included with some Operation->Material examples as the community has voted, probably focused to proven vendor profiles)

I've included template struct that will be used as default (copy / copy to "Dir")

UI would need a rethink as there's no more "materials"

[
    {
        "id":"light_v_engrave", //will be UUID
        "name":"Light Vector Engraving", //or Plywood
        "notes":"Just scribing", // or Material notes
        "template":{    // used only as initial state for any new operation
            "machine_profile":null,
            "name": null,   //autogenerate
            "type": "Laser Fill",
            "params":{
                "laser_power":"30",
                "passes":"1",
                "cut_rate":"1500"
            }
        },
        "operations":[
            {
                "machine_profile":null,
                "name": "Baltic Birch Plywood", //or Engraving :P
                "notes": null,
	        "type": "Laser Fill",
                "params":{
                    "filter_fill":"green",
                    "filter_stroke":null,
                    "laser_power":"40",
                    "passes":"1",
                    "cut_rate":"2000"
                }
            },
            {
                "machine_profile":null,
                "name": "Cast Acrylic",
                "notes": null,
                "type": "Laser Fill",
                "params":{
                    "filter_fill":"green",
                    "filter_stroke":null,
                    "laser_power":"20",
                    "passes":"1",
                    "cut_rate":"1000"
                }
            }
        ]
    } 
]

[gndprx]

Cool, didn't even think of it that way. Guess we can please everyone :)

[jorgerobles]

@gndprx, @openhardwarecoza The refactor is done. Please check it out.

[jorgerobles]

Have anyone checked the feature? If it's enough will close the issue.

(: a quick writeup on cncpro.co/administrator might help get more people testing

…

On Feb 16, 2017 9:36 AM, "jorgerobles" ***@***.***> wrote: Have anyone checked the feature? If it's enough will close the issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#39 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHVr22PSD11AllYxxds4WPwAeDmXtbgFks5rc_xigaJpZM4K3OgM> .

@jorgerobles Which branch can we check this on?

[jorgerobles]

Dev-es6 El 16 feb. 2017 9:13, "DarklyLabs" <[email protected]> escribió:

…

@jorgerobles <https://github.com/jorgerobles> Which branch can we check this on? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#39 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABoIYE5wyslUIrWm587Du9eNkCVU-a49ks5rdAULgaJpZM4K3OgM> .

@jorgerobles how is the material preset applied to an operation?

[jorgerobles]

@DarklyLabs Its under CAM:Operations: The wizard Icon, I'm just finishing documentation at cncpro.co Will be up soon http://cncpro.co/index.php/60-documentation/operations-generate-gcode/material-database

[jorgerobles]

The tabular export (CSV needs to be reworked, currently disabled.) and some other minor details (error validation) -- I've just realized now 😄

[jorgerobles]

@gndprx thanks! I did not make it public because I prefer to pick some guinea pigs before going live and have fifty people making out of context points.

[gndprx]

Quick usability request.

When editing a group or a preset, can you either add a save button or change the edit button to say save? It took me a moment to figure out how to commit my changes.

[jorgerobles]

Of course :)

[gndprx]

Sorry, I'm a pain in the rear but maybe a default color pallet selector for setting up your filter line or filter fill? Just for the basics like red, green, blue, black, yellow, etc... not a full web pallet but maybe a default 16 color pallet or something.

[jorgerobles]

Hmm. That's is tricky. It's bound with document colors. Indeed I propose to drop the filters on presets, but have to figure out how is the best way.

[gndprx]

Yeah, I figured that might be a tough one. Was just thinking out loud since many people seem to get into a pattern of "red is cut", "blue is score", "green is engrave", etc...

Not a huge issue but I'm wondering if the options should be removed if they can't be edited.

[gndprx]

Other than those few nit-picks, everything seems to work as expected and it's very fast to add/edit operations. Kudos!

[jorgerobles]

There it goes your save buttons and opened panel upon edit.
Thanks for your feedback. I will dig to find a way to drop filters on presets.

[gndprx]

Not seeing any change other than all of my presets are gone now

[jorgerobles]

hmm the changes are pushed. did you a pull on the git or using live on gh pages?

[gndprx]

I'm using the live page from git
https://laserweb.github.io/LaserWeb4/dist/

[jorgerobles]

should be visible now...

[gndprx]

Yep, looks good. Thanks.

[gndprx]

Something strange going on now that wasn't there earlier.

[jorgerobles]

@gndprx, fixed!