Ruby (eval):1: warning: Float out of range

Davidfi1

@jim said:

David, maybe you could also attach your test gcode file?

I use both attched files & I do not really know how to reproduce the warning,

I belive it is a very silple thing - remember I am very new to all of this and this is my first attempt

tri_repetier.gcode.txt

tri.gcode.txt

TIG

I notice that a lot of your @ variables are in Capitals.
Try lowercase alternatives...
@x rather than @X
etc...

Jim

I have seen that warning myself in the past, but I don't remember what the cause was. I tried importing both your gcode files, and got a nice toolpath in SketchUp and could not reproduce the warning.

I could reproduce the warning by entering eval('15.0F') in the Ruby Console, however the warning was only produced the first time. Entering the line again did not produce the warning (but a SyntaxError in both cases.)

So I have to guess you may have an incorrectly formatted gcode file, or there's a subtle bug in your parser.

'@' variables are called instance variables in the Ruby language. By convention they are lower case, but the language allows them to be upper and/or lower case.

[mod=:14ga8ufg]Topic moved to Dev forum.[/mod:14ga8ufg]

jolran

Hi.

I get this message sometimes in Hatchfaces since adding some new methods where I translate a group by 0.2.mm. Or rather setting a vectors length to that amount. In this case a clone from a face normal.

It's the same amount used(I hope I'm right) in TIG's sectioncutface to nudge geometry past the section to get visible.

I'm hoping this warning is not harmful. Havent seen any failures in my plugin cause of this yet.

Dan Rathbun

@davidfi1 said:

Problem Solved!
So simple...

What was the problem... and the solution ?

When I d/l both scripts, and open them in Notepad++, using the side-by-side Compare plugin, the only difference in the files is line 8, which you commented out. (It was opening the Ruby Console.)

Dan Rathbun

@davidfi1 said:

I was tring to see if I can write a G-Code importer to SketchUp.
Attached you can see my preleminary importer code.

Hey David,

(1) What does your importer do that the Trimble Team's STL importer does not do ?
https://github.com/SketchUp/sketchup-stl

(2) Could it be possible to merge your ideas with that project ??

Davidfi1

The problem was using capital letters as variables
The gcode importer imports G-Code
G-code in 3D production is the file that has the instruction for moving the motors of the printer.
we have lots of ways to convert from STL to G-Code, But no general tool to see the results.
I am tring to make this simple tool - if it will pruve possible technologically...

Dan Rathbun

@davidfi1 said:

I am thinking about the next steps of making this a usable plugin
What do you think?

(1) Use a more unique toplevel author namespace.

The chances are high that some other author would have the intials D and F, and so might also choose a toplevel module name DF.* The chances are low that there would be another SketchUp plugin author having the surname Fishelzon, so I would suggest using Fishelzon as a toplevel module name instead.

(2) Apache License

You should follow the advice in the Appendix entitled: "APPENDIX: How to apply the Apache License to your work" at the bottom of page:

Apache License, Version 2.0 | Apache Software Foundations

(www.apache.org)

(3) Each one of your plugins need to be separated from one another, both as to sub-module namespaces, and sub-directory filespaces.

You can also (if you choose,) further namespace group your different KINDS of plugins, by wrapping them within categorical sub-modules.
Ex:

module Fishelzon
  module Import
    module Gcode

      class Engine < Sketchup;;Importer
        # class code HERE
      end # class

      Sketchup.register_importer(Engine.new)

    end # module Gcode
  end # module Import
end # module Fishelzon

Notice how if you call Sketchup.register_importer() within the same namespace, you do not need to fully qualify the class identifier.
Since you are new to Ruby scripting, I want to emphasize the fact that you should be always evaluating code within your author namespace (at whatever level is appropriate.)
Evaluating code in the TOPLEVEL_BINDING (ie the global ObjectSpace,) should be reserved for Ruby Core Team and the Trimble Development Team (for shared API purposes.)

But this categorical separation is optional. Since it IS your namespace, you organize it as you wish.
If you do not think that you will be creating very many importer plugins, then you likely do not need a dedicated "Import" sub-module category.

File Spaces: I strongly suggest that your directory names and hierarchy follows your module namespace hierarchy. It makes things simpler.

Obviously, your author sub-directory name in the "Plugins" directory would be "Fishelzon"...

... THIS particular importer plugin's files would be in a sub-directory (at some level,) beneath your author directory.

(4) A SketchupExtension registration script is needed to go into the "Plugins" directory, so the importer can be loaded, or not, as the end user may decide via the Extension panel of the Preferences dialog.

See my tutorial: [url=http://forums.sketchucation.com/viewtopic.php?t=39094:1d8ukfjg]SketchupExtension and rbs rubies[/url:1d8ukfjg]
(It also applies to non-scrambled plugins, in general.)

(5) As shown in the example above, it would be best practice to define your importer class as a subclass of Sketchup::Importer, so it can inherit any common functionality that the Trimble Team may add into it in the future.

Normally in Ruby, a method that expects a certain class family as an argument, would do type checking, and raise a TypeError exception if the passed argument was not the expected type or a subclass.
But currently the Sketchup.register_importer() method does not do any type checking, ie, calling arg[0].kind_of?(Sketchup::Importer), but it should for best practice sake, and it might be added in a future API version. So it would be only smart to cover that issue now.* Also, we rabid rubyists like to be able to call superclass() on a class and get a meaningful result, rather than just Object. So using the example above, if we had a Ruby object browser tool, that called:
Fishelzon::Import::Gcode::Engine.superclass
we would want to see the output:
Sketchup::Importer

Dan Rathbun

@davidfi1 said:

The problem was using capital letters as variables ...

OK, yes simple fix.

BTW... the initialize() method is still init'g 3 instance vars with uppercase names.

Dan Rathbun

I am looking at it now.

I made up the "load_Fishelzon_GcodeImporter.rb" SketchupExtension loader script, by using another file as a template.

I notice you added a "*.bfb" extension ??

@unknownuser said:

](http://www.sketchup.com/intl/en/developer/docs/ourdoc/importer#file_extension)":21ewphmz]Ruby importers are only allowed to support a single extension.

What is different about the ".bfb" extension from the ".gcode" extension ??
EDIT: Oh I see it is a Bits-From-Bytes specific gcode file.

Davidfi1

Problem Solved!
So simple...

Thank you.

I am thinking about the next steps of making this a usable plugin
What do you think?

Davidfi1

Well,
I tried
Please see my attempt to follow your advice.
I did not do the instruction in "[ code ] SketchupExtension and rbs rubies" yet...

thank you
Hope this importer will be usable.
It seems that it take a long time to import the gcode
And what is worse is the time it take for sketchup to render the lines that where imported.

I am looking for a way to make it easier for sketchup to render - can you help?

Davidfi1

Dan,
I made some progress making this importer a little more usable.
Pleas see if you have more advice for me.

P.S. I deleted all the old versions from this thread
and updated the top thread's file.
Thank you.
David.