Slic3r / Win64 post processing script setup

Greets -
I've been attempting to get Slic3r post scripts running in a Win64 environment, but no luck.
I do have a working (standalone) Slic3r 0.9.10b running fine, with CitrusPerl installed as well as the dependencies to build Slic3r from scratch. I am not running Slic3r from source, just the precompiled package.
I've been testing with the post scripts included in the Slic3r package, and am confused as I'm not getting an actual error thrown to track down.

I've placed the script in the root of my d: drive, and specified its use in the Print Settings>Post field. I've used both back slashes (win) and forward slashes (unix) styling, such as (d:/slic3r_postprocess.pl and d:\slic3r_postprocess.pl). Neither seems to change the response. Since it's a text script, there is no chmod functionality in the Win environ; it is however "unblocked" and has all fully available permisions (yuk, security breach, "Everyone" gets "Full Access" for now)....

The slicing happens as expected, the app begins to write the gcode output, then it opens up a notepad window with the script in it. That's it.
Originally, I thought that perhaps just the extension was assigned to notepad, but it is assigned to be opened by perl.exe by default. There is no "hidden" additional extension (I show full path and title on all my files by default.)

Then to check this, I assigned the script to be opened by Wordpad, and reran the slice; lo and behold, it opened with Wordpad. Odd, but expected. I re-assigned it back to perl.exe and reran. Finally a terminal window opened up and immediately closed; no errors. Windows properties showed it as being openable by perl.exe by default. Perhaps a glitch. Still, no change to the output. Every so often (like every 5 attempts to run), Slic3r will actually hang.

This gets me thinking that it's a perl configuration somewhere, or the traditional perl headers are not compatible while running in Win (or mingw).
Additionally, I have also run citrusterm in another window to ensure that there is a perl instance available. (also no change, and no output from that console at all).

No need to hate on the Win environ; I'm just as confortable in Linux, but my modeling environment is in Windows, so working on this current project would be much easier if I can keep it inside the same OS, at least for now.

Googling this topic shows pretty much no tested tutorial on a Windows platform for post scripts; there is some info on using it in a Linux environ, that is "pseudo translated" to Windows, but it's evident the posters just assumed things would work.

Does anyone have tested valid experience dowing this in Win?

Thanks,
Ted.

It's probably opening notepad because that's the app that is associated with .pl files. I've never user the postprocessing option, but can't you just specify perl on the command line?

Eg. Instead of "script.pl", try "perl script.pl"

J-
the notepad weirdness has [offically] come and gone, per above; it seems to have been a CitrusUtils glitch. Doubleclicking the script at any time in the experience always did run the script in a perl terminal; of course since the script was expecting a file to be passed to it, it would hang in that method, but that is normal behaviour.

For giggles, I tried a clean "hello world test with keypress" test; and Slic3r does hang on that script; this tells me that it is invoking the script and perl; just without a terminal window. Since there's no terminal window for STDIN to process, there's no way to conclude the test script, so Slic3r hangs, waiting for a never-to-come keypress.

If I try just a print"hello" with no additional code, the process completes, but no indication that it actually invoked the script (but given the tests so far, I would assume it did).

Is there a way to force the opening of the opening of a terminal window so I can at least see or test the script progression?

Adding the perl prefix in the post-processor field window just got skipped; it didn't even get stalled on the script, so one might assume that items in the window are invoked that way already, thus it tried to call "perl perl d:...." and backfired.

Thanks,
Ted.

To see if your test script is running, echo something info a file with standard output redirection using the greater than key

[slaps head] Of course. Or any other non-infered output. (Per your suggestion, I did also do a simple STDOUT redirect in Slic3r, but evolved to the method shown below as it's more explicit)

Which works. It did turn up some odd path naming

use strict;
use warnings;

print "A printed text line";

open OUTPUT, ">d:/output.txt";
print OUTPUT "This is some output\n";
close OUTPUT;

Only "This is some output" appears in the text file in the root of my d: drive. (As one would expect.)

I've not used the redirect inside a filename before such as above, but it doesn't work without it. Given that, I'm finally on the path to getting some post-script going.

BTW - for completeness of anyone else searching posts, the above script (named script.pl) was located in the root of my D: drive, and called with the line in Slic3rs Print Settings> Output Options> Post Processing Scripts form window as:

d:\script.pl

Note the forward slash in the script code and the backward slash in the call in Slic3r - other methods don't produce the same results!
Now on to bigger and more useful things...

Thanks for the patience!

Ted

Sorry for reopen this topic...I have same problem with windows 8.1 64 bit.
I test with this script:

use strict;
use warnings;

print "A printed text line";

open OUTPUT, ">d:/output.txt";
print OUTPUT "This is some output\n";
close OUTPUT;

And function perfectly, but if i use script: filament-weight.pl or flowrate.pl or z-every-line.pl not function.

I have Slic3r 1.0.7, repetier Host 1.0 and perl 5.16.3
Please help me...

P.S. sorry for my bad english

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse

I testing with Win 7 64 bit, now the script function, first with Win 8 64-bit Slic3r crashed, but now ends prosprocessing but the final gcode does not change.
I have tried both launching from the Slicer repetier, both directly by making Slic3r.
Can anyone help me in some way!

---

COMPRA ITALIANO - sostieni le nostre aziende - sostieni la nostra gente - sostieni il tuo popolo - sosterrai te stesso.
Alberto C. felice possessore di una Kossel K2
My Blog - My Thingiverse